Re: caching questions
On Tue, 22 Jul 2003 13:05:00 +0300, Stas Bekman wrote: > Peter Haworth wrote: > > Cache::Mmap (which I wrote) isn't threadsafe, but should work OK in a > > forking MPM. If anyone wants to contribute code to make it threadsafe > > (preferably without impacting single-threaded performance too much), > > I'll be very grateful. I'd do it myself, but I've never used threads, so > > I'm bound to get it wrong. > > I haven't looked at the module's implementation, but if you have a C-level > thread-safety issues, you may consider using libapr which provides a > thread-safe mmap API. No, it's perl-level stuff at the point that matters. Currently, it uses fine grained file locking to prevent concurrent accesses from other processes, but as far as I understand it, this won't prevent concurrent accesses from other threads in the same process. -- Peter Haworth [EMAIL PROTECTED] "Do you expect me to implement it?" "No, Mister Schwern, I expect you to DIE!" -- Michael G Schwern in p5p
Re: caching questions
On 22 Jul 2003 08:13:43 +0200, Tom Schindl wrote: > Am Mon, 2003-07-21 um 21.45 schrieb Perrin Harkins: > > On Sun, 2003-07-20 at 15:47, Patrick Galbraith wrote: > > > I know there's IPC, and also memcached. I've used IPC::Shareable > > > before, but don't know if that's the route I'd wanna go. > > > > It's not. IPC::Shareable is very slow. If you want to share data, use > > Cache::FileCache, Cache::Mmap, MLDBM::Sync, or IPC::MM. > > Sorry to step in here, but could I use any of the caching modules you > mentionned in mod_perl2? Cache::Mmap (which I wrote) isn't threadsafe, but should work OK in a forking MPM. If anyone wants to contribute code to make it threadsafe (preferably without impacting single-threaded performance too much), I'll be very grateful. I'd do it myself, but I've never used threads, so I'm bound to get it wrong. -- Peter Haworth [EMAIL PROTECTED] "[That sentence] occupied the table running through the middle of the middle room in a half-way house. It was so equidistant that it managed to find a patch of gravitic stability, a Lagrange of Reason, within which it set up a giant tubular space station of the type that NASA were hoping to build by 2010." -- Ashley Pomeroy
Re: untainting PATH in mod_perl
On Tue, Jul 15, 2003 at 04:30:35PM +0300, Stas Bekman wrote:
> Peter B. Ensch wrote:
>
> >>FWIW, I use the following code when I need to use ``|qx:
> >>
> >>local $ENV{PATH} = "/bin:/usr/bin";
> >>local @ENV{ qw(IFS CDPATH ENV BASH_ENV) };
> >
> >But this code must be used in each scope where you intend to use
> >backticks, a system call Etc. Is there no way to untaint your
> >PATH environment one time for the script or handler?
>
> If you write code used by other people this is probably the only way to go.
> This is because you want to control the setting. What if PATH gets
> untainted at the server startup, but then some other module sets a new
> tainted value to $ENV{PATH}? So it's a good habit to have it local to the
> code that you run.
>
> Besides helps to avoid forking external processes. If you can rewrite your
> code:
>
> foreach(`/bin/ls $path`) {
>
> }
>
> (which is probably not the real code), not to `` but to read the file in,
> and process it, you eliminate the whole problem altogether. I realize that
> this is not always possible.
>
> How about abstracting untaint and `` into a single function:
>
> sub backticks {
> local $ENV{PATH} = "/bin:/usr/bin";
> local @ENV{ qw(IFS CDPATH ENV BASH_ENV) };
> qx(@_);
> }
>
Stas,
Thanks for your explanation and suggestion. I'm a lot clearer on this
issue now.
P.
--
^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^
Peter Ensch,
[EMAIL PROTECTED] A-1140 (214) 480 2333
^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^
Re: untainting PATH in mod_perl
On Tue, Jul 15, 2003 at 12:19:14PM +0300, Stas Bekman wrote:
> Dominique Quatravaux wrote:
> >> Sorry, getting out of good ideas..
> >
> >
> > Surprise, surprise: I found out that my code does not work under
> >mod_perl 1.23 either! And I found the real solution: one has to add
> >
> > PerlSetupEnv Off
> >
> >to the Apache configuration file. Now the untainting mumbo-jumbo in
> > section works.
> >
> > Warning: this has the consequence of breaking the part of the CGI
> >environment emulation that deals with environment (e.g. instead of
> >$ENV{"HTTP_USER_AGENT"}, you now have to check
> >Apache->request()->subprocess_env("HTTP_USER_AGENT")). Glancing at its
> >source code, I don't think CGI.pm will survive that...
> >
> > BTW, I finally got around to reading mod_perl's source, and it
> >is now clear to me that the environment, when being copied from
> >->subprocess_env() into %ENV, gets tainted (around line 704 in
> >src/modules/perl/mod_perl.c). The whole %ENV gets tainted, not just
> >the HTTP_USER_AGENT and such from the CGI context, so PATH is tainted
> >as well. This explains our now common problem - and also guarantees
> >that there is no easy way out of it if you use CGI.pm yourself :-(.
>
> You need to untaint the variables before you use them. Since they get reset
> on every request, you need to untaint them inside your script/handler's run
> time, not the BEGIN block...:
> http://perl.apache.org/docs/1.0/guide/porting.html#BEGIN_blocks
>
> it should work just fine with mp1 and mp2.
>
> Relying on 'PerlSetupEnv Off' is not a very good idea, since if you want to
> release your code for others to use, they may not be able to turn it off,
> since it'll break their CGI-legacy code as you have observed.
>
> FWIW, I use the following code when I need to use ``|qx:
>
> local $ENV{PATH} = "/bin:/usr/bin";
> local @ENV{ qw(IFS CDPATH ENV BASH_ENV) };
>
>
But this code must be used in each scope where you intend to use
backticks, a system call Etc. Is there no way to untaint your
PATH environment one time for the script or handler?
P
--
^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^
Peter B. Ensch ([EMAIL PROTECTED])
Linux 2.4.20-4GB 5:47am Up 2 days 18:47
^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^
Re: untainting PATH in mod_perl
On Thu, Jul 10, 2003 at 10:25:59AM +0200, Dominique Quatravaux wrote:
> > I need some help with this. Can you share the code you use w/in
> > your section?
>
> Sure! Here is how I untaint a selected range of variables from the
> WWW server's %ENV, and discard all the others (good move to ease
> debugging anyway):
>
># From httpd.conf
>PerlTaintCheck On
>
>
> BEGIN {
># Untaint environment. Those variables come from
># Apache; even if they didn't, they would come from the root
># user who launched Apache. No security problems here.
>
>my %cleanenv;
>foreach my $var (qw(PATH GATEWAY_INTERFACE MOD_PERL)) {
> ($cleanenv{$var})=($ENV{$var} =~ m/^(.*)$/g);
>}
>%ENV=%cleanenv;
>}
>
>
> > I'm pretty confused because I was able to untaint my PATH var.
> > by putting
> >
> > $ENV{PATH} = '/bin';
> >
> > in the ***same scope*** where I was getting the error.
>
> Makes sense to me: if you are using Apache::Registry (for example),
> your script only gets compiled once and the BEGIN blocks run at that
> time. In fact Apache::Registry reads your cgi, then cooks it into
> something like this:
>
> package Some::Name::Made::Up::By::Apache::Registry::To::Isolate::Your::cgi;
>
> sub handler {
> # Your script here
> }
>
> Then it evals that (by that time, the BEGIN blocks run), then calls
> Some::Name::...::handler(). The purpose of these steps is caching: the
> next time the CGI is hit, the evalling needs not be redone, only the
> handler call.
>
> Now, my guess was that %ENV gets reset between the eval and the
> handler call. As you mention, putting the untainter in the same scope
> solves the problem, because you now circumvent the cleaning. Putting
> it in the section should also solve the problem once for all,
> because the section runs before the default %ENV value is
> stashed (even before Apache forks, in fact).
>
Dominique,
Thanks for sharing your code; unfortunately, it's not working for me.
I copied it into my httpd.conf file, stopped/started the server and
I still get the same error:
[Thu Jul 10 11:10:38 2003] [error] 19156: ModPerl::Registry: Error executing run mode
'getlib': \
Insecure $ENV{PATH} while running setgid at
/opt/asic/http/2.0.46/worker/perl-lib/Webace/Art.pm line 386
where line #386 is:
foreach my $release (`/bin/ls $path`) { # $path is already untainted
}
Any other ideas?
Thanks and regards,
P
--
^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^
Peter Ensch,
[EMAIL PROTECTED] A-1140 (214) 480 2333
^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^
Re: untainting PATH in mod_perl
On Wed, Jul 09, 2003 at 05:40:32PM +0200, Dominique Quatravaux wrote:
> > In plain CGI, I normally do this inside a BEGIN
> > block; in mod_perl however, this doesn't work.
>
> This would work if this was done in a section of the httpd.conf
> file (this is what I do). I am not sure why the BEGIN block is not
> executed, but my guess is that the environment gets automatically
> restored at the end of every script run under Apache::Registry,
> including the tainted PATH.
>
I need some help with this. Can you share the code you use w/in
your section?
I'm pretty confused because I was able to untaint my PATH var.
by putting
$ENV{PATH} = '/bin';
in the ***same scope*** where I was getting the error. For example
$ENV{PATH} = '/bin';
my @files = `/bin/ls $path`; # $path is already untainted
was OK; leave out the $ENV line and I get an Insecure $ENV{PATH}
error.
This works (don't know why) but I would prefer to fix the PATH
in one place rather than having to do so everywhere I shell out
or use backticks.
Thanks,
P
--
^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^
Peter B. Ensch ([EMAIL PROTECTED])
Linux 2.4.20-4GB 8:21pm Up 18 days 2:55
^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^
untainting PATH in mod_perl
perlsec says that to untaint the PATH env one should
do:
$ENV{'PATH'} = '/bin:/usr/bin';
delete @ENV{'IFS', 'CDPATH', 'ENV', 'BASH_ENV'};
In plain CGI, I normally do this inside a BEGIN
block; in mod_perl however, this doesn't work. A
print of $ENV{PATH} returns the original tainted
PATH.
In my script I'm doing something like
foreach(`/bin/ls $path`) {
}
$path is already untainted but I'm still getting
an 'Insecure $ENV{PATH}' error. What am I missing
here?
Thanks,
P
--
^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^
Peter Ensch,
[EMAIL PROTECTED] A-1140 (214) 480 2333
^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^
Re: require'ing data files under mod_perl
On Thu, Jul 03, 2003 at 05:15:31PM -0400, Perrin Harkins wrote: > On Thu, 2003-07-03 at 16:59, Peter Ensch wrote: > > OK. Thanks. Well, yes it is being reloaded whenever the form > > is submitted and w/out restarting the server. Here's some of > > the output (error_log): > > > > [Thu Jul 3 15:52:00 2003] users.dat: users.dat loaded by process 18294 at > > /opt/a... > > > > Just a guess, but maybe this is because you're passing a variable to the > require function. Try hard-coding it and see if it changes. > This sounded like a good explanation but it wasn't. Hard-coding the require'd file didn't make any difference; nor did the assignment to a variable. In each case the require'd file was reloaded each time the script was invoked. It's a mystery! P -- ^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^ Peter Ensch, [EMAIL PROTECTED] A-1140 (214) 480 2333 ^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^
Re: require'ing data files under mod_perl
On Thu, Jul 03, 2003 at 04:24:35PM -0400, Perrin Harkins wrote: > On Thu, 2003-07-03 at 16:16, Peter Ensch wrote: > > > > So, to reiterate, I may write to users.dat on one transaction > > > > and read on another; the file contents is always up-to-date. > > > > > > The file is up-to-date, or the param 'users' is? > > > > > > > The file is. IE. it gets written and and the new stuff is available > > by simply reloading the page. > > Well, the file getting written is not related to require loading each > time or not. The thing that I would not expect to change is the > in-memory data. > > > > Why don't you debug it a little by putting a warn statement in your > > > users.dat file that prints the process ID? Then you can tell if it is > > > truly being executed more than once by the same process. > > > > > > > Hmm. Not sure how to do that w/out messing w/ the headers and > > making the app. crash. How would I do that? > > Before the hash stuff in the file, put in a statement like this: > > warn "users.dat loaded by process $$"; > OK. Thanks. Well, yes it is being reloaded whenever the form is submitted and w/out restarting the server. Here's some of the output (error_log): [Thu Jul 3 15:52:00 2003] users.dat: users.dat loaded by process 18294 at /opt/a... [Thu Jul 3 15:52:00 2003] users.dat: users.dat loaded by process 18294 at /opt/a... [Thu Jul 3 15:52:00 2003] users.dat: users.dat loaded by process 18294 at /opt/a... [Thu Jul 3 15:52:03 2003] users.dat: users.dat loaded by process 18294 at /opt/a... [Thu Jul 3 15:52:04 2003] users.dat: users.dat loaded by process 18294 at /opt/a... [Thu Jul 3 15:52:06 2003] users.dat: users.dat loaded by process 18294 at /opt/a... [Thu Jul 3 15:52:32 2003] users.dat: users.dat loaded by process 18294 at /opt/a... [Thu Jul 3 15:52:33 2003] users.dat: users.dat loaded by process 18338 at /opt/a... [Thu Jul 3 15:52:34 2003] users.dat: users.dat loaded by process 18338 at /opt/a... [Thu Jul 3 15:53:00 2003] users.dat: users.dat loaded by process 18338 at /opt/a... [Thu Jul 3 15:53:03 2003] users.dat: users.dat loaded by process 18338 at /opt/a... [Thu Jul 3 15:53:05 2003] users.dat: users.dat loaded by process 18338 at /opt/a... [Thu Jul 3 15:53:22 2003] users.dat: users.dat loaded by process 18338 at /opt/a... [Thu Jul 3 15:53:25 2003] users.dat: users.dat loaded by process 18338 at /opt/a... [Thu Jul 3 15:53:28 2003] users.dat: users.dat loaded by process 18338 at /opt/a... [Thu Jul 3 15:53:28 2003] users.dat: users.dat loaded by process 18338 at /opt/a... Here are the httpd process: [490] % ps -Alf |grep apache 8 S root 17921 ... /apps/apache/http/2.0.46/worker/bin 8 S apache 18338 ... /apps/apache/http/2.0.46/worker/bin 8 S apache 18336 ... /apps/apache/http/2.0.46/worker/bin 8 S apache 18337 ... /apps/apache/http/2.0.46/worker/bin So. What's going on? I'm not using A::Reload. P -- ^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^ Peter Ensch, [EMAIL PROTECTED] A-1140 (214) 480 2333 ^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^
Re: require'ing data files under mod_perl
On Thu, Jul 03, 2003 at 02:51:23PM -0400, Perrin Harkins wrote:
> On Thu, 2003-07-03 at 13:38, Peter Ensch wrote:
> > I'm using CGI::Application and this part of the code happens inside
> > the cgiapp_init() method which I'm overriding:
> >
> > our $USERS : unique = "/path/to/users.dat";
> >
> > sub cgiapp_init {
> > my $self = shift;
> > $self->param('users' => require ${\$USERS});
> > }
>
> That's confusing code. Your users.dat file is a chunk of code that
> returns a value that you use? A little obscure, in my opinion. And
> what's that stuff with the ref/de-ref syntax for?
The file contains a simple hash ref. like
{
duck => 'quack',
dog => 'woof',
cat => 'meow',
}
The ref/de-ref was a mistake; a hold over from when USERS was a
constant (and which didn't interpolate in a require). Now it's
$self->param('users' => require $USERS);
>
> > So, to reiterate, I may write to users.dat on one transaction
> > and read on another; the file contents is always up-to-date.
>
> The file is up-to-date, or the param 'users' is?
>
The file is. IE. it gets written and and the new stuff is available
by simply reloading the page.
> Why don't you debug it a little by putting a warn statement in your
> users.dat file that prints the process ID? Then you can tell if it is
> truly being executed more than once by the same process.
>
Hmm. Not sure how to do that w/out messing w/ the headers and
making the app. crash. How would I do that?
P
--
^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^
Peter Ensch,
[EMAIL PROTECTED] A-1140 (214) 480 2333
^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^
Re: require'ing data files under mod_perl
On Mon, Jun 30, 2003 at 05:28:43PM -0400, Perrin Harkins wrote:
> On Sat, 2003-06-28 at 15:08, Peter B. Ensch wrote:
> > Coding in plain CGI I've often require'd files containing
> > data in perl data-structures. The script may write to the
> > file (via Data::Dumper for example) allowing subsequent
> > invokations of the script to have access to the revised
> > data.
>
> It would be simpler and faster to use MLDBM::Sync for this.
>
Not familiar w/ this module and it's not on our system; I'll
certainly look into it.
> > I was expecting this methodology to break under mod_perl
> > thinking that the require would only happen once (the
> > first time the script runs after server startup); however,
> > it seems to be working the way it always did.
> >
> > Why is this? Am I missing something?
>
> Can't tell without seeing some code. Your require'd files with not be
> reloaded unless you are using Apache::Reload or Apache::StatINC to force
> them.
>
I'm NOT using A::Reload or A::StatINC. My script appears to be
require'ing the data file on each user transaction, just like
under plain CGI.
I'm using CGI::Application and this part of the code happens inside
the cgiapp_init() method which I'm overriding:
our $USERS : unique = "/path/to/users.dat";
sub cgiapp_init {
my $self = shift;
$self->param('users' => require ${\$USERS});
}
So, to reiterate, I may write to users.dat on one transaction
and read on another; the file contents is always up-to-date.
I still can't understand why this is because I did not think
it would be reloaded unless the server was restarted.
BTW - it doesn't have anything to do with the 'unique' our
attribute; same behavour with or without.
I'm new to apache and I'm not running in single-process mode;
this shouldn't have a bearing should it?
Thanks,
P
--
^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^
Peter Ensch,
[EMAIL PROTECTED] A-1140 (214) 480 2333
^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^
require'ing data files under mod_perl
Coding in plain CGI I've often require'd files containing data in perl data-structures. The script may write to the file (via Data::Dumper for example) allowing subsequent invokations of the script to have access to the revised data. I was expecting this methodology to break under mod_perl thinking that the require would only happen once (the first time the script runs after server startup); however, it seems to be working the way it always did. Why is this? Am I missing something? Thanks, P -- ^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~ Peter B. Ensch ([EMAIL PROTECTED]) Linux 2.4.20-4GB 12:00pm Up 6 days 18:33 ^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~
A::Registry vs. mod_perl handler philosophy
I'm beginning to develop apps under mod_perl. I'm curious as to how people decide between coding for Apache::Registry vs. mod_perl handlers. It's been suggested to me that content generating apps should be done under A::R, whereas logging, authentication Etc. should be implemented as mod_perl handlers. What is the opinion of the group? Regards, P -- ^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^ Peter Ensch, [EMAIL PROTECTED] A-1140 (214) 480 2333 ^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^
ANNOUNCE: Cache::Mmap 0.07
Anyone running 0.05 on perl 5.6.0 or later should upgrade to this version, unless they are absolutely sure that none of their cached data contains UTF8 encoded characters. I didn't think my data did, but my caches were exhibiting some very peculiar behaviour because of it. >From the README: This module provides a shared cache, using a memory mapped file. Very useful for mod_perl applications. If routines are provided which interact with the underlying data, access to the cache is completely transparent, and the module handles all the details of refreshing cache contents, and updating underlying data, if necessary. Changes since version 0.05 Add a check for super-sized entries (those which extend past the bucket end) Make zero-sized check message include cache filename and key Add t/03corrupt.t to check that the corruption checks are working Deal with utf8 properly (and add t/04utf8.t) This changes the file format, so added format version number to file header Existing files which aren't cache files are not overwritten From: PAUSE <[EMAIL PROTECTED]> To: "Peter Haworth" <[EMAIL PROTECTED]> Subject: CPAN Upload: P/PM/PMH/Cache-Mmap-0.07.tar.gz Date: Tue, 17 Jun 2003 20:54:32 +0200 The uploaded file Cache-Mmap-0.07.tar.gz has entered CPAN as file: $CPAN/authors/id/P/PM/PMH/Cache-Mmap-0.07.tar.gz size: 19897 bytes md5: 1288f95fa9a86a83c0884602b69597f1 No action is required on your part Request entered by: PMH (Peter Haworth) Request entered on: Tue, 17 Jun 2003 18:52:52 GMT Request completed: Tue, 17 Jun 2003 18:54:32 GMT Thanks, -- paused, v343 -- Peter Haworth [EMAIL PROTECTED] "i like Sample A because it tastes great and is less typing." -- brian d foy in c.l.p.misc
Re: Authentication design
There are at least 2 places where the idea can be improved to be even better: 1) for browsers that do not support cookie, embed the ticket/credential in the URL so the system works for all browsers 2) the part for ticket verification can be written in C so in case of dual-server setup (light plus proxy), which is kind of popular now, one can set it up in the light server to protect static content. Peter - Original Message - From: "Michael L. Artz" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, June 10, 2003 6:47 PM Subject: Re: Authentication design > > Well, sorta. I am actually using a custom module very similar to the > one found in the cookbook (and AuthCookie, I think), i.e. create a > PerlAuthenHandler that sets the custom error message to the login page > and redirects you to it if you pass it an incorrect user/password > request. If it the user/pass checks out, I set a session cookie (md5 > sum of stuff), store the session_key in the database (Postgres), and set > $r->user. If no user/password or cookie is presented, I just return OK > for most of the site. A couple of scripts are "login-only", and those > are protected by an authz handler that makes sure $r->user is set. > Everything is handled with my custom login forms, none of the crappy > pop-ups for basic or digest authentication. So I guess that I am > usurping the normal HTTP-authentication phase for my own nefarious purposes. > > I thought that this was a good way to go since I could protect my entire > application with a single module and a couple lines in the config file, > as opposed to bundling that authentication code into the beginning of > *every* registry script that I write. And, from lurking on the board > for a long time, I got the feeling that this is how everyone is doing it > is that a correct assumption? > > -Mike > > >
RE: Cookie-free authentication
hi all www.wgsn.com is a subscription based service that doesn't use cookies for authentication. we use basic auth. I would like to share what i consider "how not to implement cookie-free authentication". there are three tiers to our website tier 1 is apache with mod_perl doing authentication and mod_proxy passing requests to tier 2 tier 2 is a content management server tier 3 is the database server. tier 3 stores the raw content, tier 2 puts the bits from the db server together and tier 1 logs the hit and sends it to the client, nothing too fancy here. our authentication has two main bits that suck. first is subscribers have their username and password mapped to a special username and password for the content management systems, which differs on varying levels of subscriptions. as an example, the apache servers may recognize n valid usernames and passwords, while the cms only recognizes 3. this mapping is done via an apache module written in perl, which talks to a series of perl scripts that keep a copy of the user database. when a request comes in to the apache servers, the module maps the customer username/pass to the content management username/pass, rewrites the Authorization: header, and mod_proxy sends the request to tier 2. this sounds reasonably simple, but in the real world it's one big bit of mush of unpleasant stuff that falls over every other week. why that is i've never been able to exactly put my finger on, but i have a feeling it was developers letting their personal preferences getting in the way of business needs, by ignoring existing standards or best practices, and going out to re-invent a better wheel. the second (and imo bigger) bit that sucks is because we do silly things like re-writing incoming http headers and cleaning them as the response goes back out, we can't utilize things like caching as effectively as we could if we were using cookies. the reason for this is due to our requirement that we must see which users are accessing which areas of the site (so we can see what's popular etc). The information we require is stored in these re-written headers. This means we need our downstream caching hierarchy (which is a 3rd party) to send at least an If-Modified-Since request for images (some of which we allow to be cached), and we cannot allow them to cache our html documents. If we used cookies our caches could authenticate & log hits at the caching server nearest the client instead of having to come back to our origin servers for every single hit. in busy periods we serve around 2.5 million objects a day, nothing really major, but enough to make things like this a significant drain on our resources (which are limited as always :) for the reasons above, we are investigating the transition to cookie based authentication. i suppose it really depends on what you are developing, but take heed. i fully understand why cookie based authentication may be unacceptable, but consider maintainability and (long-term) scalability when you're doing your design and implementation. in the end you'll save someone a few grey hairs :) -pete > -Original Message- > From: Geoffrey Young [mailto:[EMAIL PROTECTED]] > Sent: Thursday, December 12, 2002 1:44 PM > To: Ron Savage > Cc: Apache mod_perl > Subject: Cookie-free authentication > > > > > Ron Savage wrote: > > On Wed, 11 Dec 2002 13:58:18 -0700, Nathan Torkington wrote: > > > [snip] > > > > Some of us are trying to implement > authentication/login/logout where, > > if at all possible, cookies are not to be used. A cookie-free > > discussion would be most welcome. > > I've done a bit of preliminary work with using Digest > authentication to accomplish this - > see Session.pm in Apache::AuthDigest, the latest copy of > which can be found here > > http://www.modperlcookbook.org/~geoff/modules/Apache-AuthDiges > t-0.022.tar.gz > > it's fairly new interface, and I've only toyed with it > (though there is _some_ > documentation :). however, it seems to me that (for clients > that can support this > implementation of Digest, which seems to be just about > everyone but MSIE) the nonce > provides exactly the kind of state information that is > required for login/logout > authentication. > > of course, it trades cookies for that pop-up box (again), so > if you're looking for > cookiless, HTML form based logins, then it's probably not > what you want. > > --Geoff >
modperl file cache screwed up
Hi, on my installation of Apache (1.3.27 + last Modperl) I have the problem that on two diffrent virtual servers, there are perl CGIs with the same name but entirely diffrent funcions. I have the effect that sometimes when asking to execute the CGI of server1, the CGI of server2 is run and sends its output. Did I miss something? Does the cache not handle virtual servers correctly? (e.g. cache by filename, not by entire URL) Or do I have to set a variable in the section of each server? Sorry, I'm quite unfamiliar with Apache/Perl. Thanks! Peter -- ITServ: kompetent, zuverlässig und fair - ITServ GmbH Peter Bauer Phone:++49 (0)700 487378-33 Roentgenstrasse 11-or- ++49 (0)700 ITSERV-DE D-65474 Bischofsheim Fax: ++49 (0)700 487378-32 GERMANY -or- ++49 (0)700 ITSERV-FA Mail: [EMAIL PROTECTED] Mobile : ++49 (0)172 9391076 -
Quota module for Perl
Hi, i am trying to install the Quota module for Perl, but following error occurs: I´ve installed RedHat 7.1 mod_perl 1.24_01-2 perl 5.6.0-12 Has anyone got an idea? Regards Peter cpan> install Quota Running install for module Quota Running make for T/TO/TOMZO/Quota-1.4.6.tar.gz CPAN: Digest::MD5 loaded ok Checksum for /root/.cpan/sources/authors/id/T/TO/TOMZO/Quota-1.4.6.tar.gz ok Scanning cache /root/.cpan/build for sizes Quota-1.4.6/ Quota-1.4.6/CHANGES Quota-1.4.6/INSTALL Quota-1.4.6/MANIFEST Quota-1.4.6/Makefile.PL Quota-1.4.6/Quota.pm Quota-1.4.6/Quota.xs Quota-1.4.6/README Quota-1.4.6/hints/ Quota-1.4.6/hints/solaris_2.h Quota-1.4.6/hints/sunos_4_1.h Quota-1.4.6/hints/none.h Quota-1.4.6/hints/linux.h Quota-1.4.6/hints/irix_6.h Quota-1.4.6/hints/irix_5.h Quota-1.4.6/hints/aix_4_1.h Quota-1.4.6/hints/hpux.h Quota-1.4.6/hints/dec_osf.h Quota-1.4.6/hints/bsd.h Quota-1.4.6/test.pl Quota-1.4.6/contrib/ Quota-1.4.6/contrib/README Quota-1.4.6/contrib/report-quota Quota-1.4.6/contrib/quotamgmt/ Quota-1.4.6/contrib/quotamgmt/Author Quota-1.4.6/contrib/quotamgmt/config Quota-1.4.6/contrib/quotamgmt/quotamgmt Quota-1.4.6/contrib/test-group.pl Quota-1.4.6/contrib/mount-list.pl Quota-1.4.6/contrib/mount-list-qcarg.pl Quota-1.4.6/include/ Quota-1.4.6/include/rquota.h Quota-1.4.6/include/afsquota.h Quota-1.4.6/include/stdio_wrap.h Quota-1.4.6/include/vxquotactl.h Quota-1.4.6/include/quotaio_xfs.h Quota-1.4.6/stdio_wrap.c Quota-1.4.6/afsquota.c Quota-1.4.6/vxquotactl.c Quota-1.4.6/linuxapi.c Removing previously used /root/.cpan/build/Quota-1.4.6 CPAN.pm: Going to build T/TO/TOMZO/Quota-1.4.6.tar.gz Using hints/linux.h for myconfig.h Checking if your kit is complete... Looks good Configured without AFS support Writing Makefile for Quota cp Quota.pm blib/lib/Quota.pm AutoSplitting blib/lib/Quota.pm (blib/lib/auto/Quota) /usr/local/bin/perl /usr/local/lib/perl5/5.8.0/ExtUtils/xsubpp -typemap /usr/local/lib/perl5/5.8.0/ExtUtils/typemap Quota.xs > Quota.xsc && mv Quota.xsc Quota.c rm -f myconfig.h ln -s hints/linux.h myconfig.h cc -c -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -DVERSION=\"1.4.5\" -DXS_VERSION=\"1.4.5\" -fpic "-I/usr/local/lib/perl5/5.8.0/i686-linux/CORE" Quota.c In file included from Quota.xs:11: myconfig.h:21:27: rpcsvc/rquota.h: Datei oder Verzeichnis nicht gefunden make: *** [Quota.o] Fehler 1 /usr/bin/make -- NOT OK Running make test Can't test without successful make Running make install make had returned bad status, install seems impossible cpan>
Re: Thoughts on Mason?
On 24 Oct 2002 at 15:13, Shannon Appelcline wrote: > I see there's a new book coming out from O'Reilly on "mason", which > seems to be perl integrated into web pages and claims to support > mod_perl. > > http://www.masonbook.com/ > > Any thoughts on mason from this esteemed community? I've never used it, but FWIW, I recently interviewed at Amazon and they told me they are looking for more Perl programmers because they plan to use Mason. Peter
Re: AuthCookie questions
check here http://modperl.home.att.net Peter - Original Message - From: "Christian Gilmore" <[EMAIL PROTECTED]> To: "'Michael Schout'" <[EMAIL PROTECTED]> Cc: "'Modperl Mailing List (E-mail)'" <[EMAIL PROTECTED]> Sent: Tuesday, October 22, 2002 12:13 PM Subject: RE: AuthCookie questions > Hi, Michael. Let me try again with more specifics. I'm required to mash my > service into another organization's authentication scheme, ditching my own > secure methods for their cross-domain unencrypted, unsigned cookie. > > 1. Foreign server, foreign.foo.com, presents a form to a user requesting > userid/password. Foreign server accepts credentials and creates simple > session cookie whose domain is foo.com containing a string of > unencrypted key/value pairs. > 2. User comes to my local server, local.foo.com, and sends along his > cookie for domain foo.com. I need to parse out one of the key/value > pairs and populate an environment variable (aside from REMOTE_USER) > with the pair's data. If the user comes without the cookie or without > appropriate data in the cookie, I need to redirect him to foreign. > > I am also asked to not create any other cookies. All the data I need is in > the one cookie that comes from foreign. So, my needs boil down to: > > 1. Read data from existing cookie. > 1a. Redirect if cookie is non-existent. > 2. Accept or reject cookie. > 2a. If rejected, redirect. > 2b. If accepted, populate environment and return. > > On a side note, if anyone finds the proposed design lacking for security or > anything else, please let me know. > > Thanks, > Christian > > - > Christian Gilmore > Technology Leader > GeT WW Global Applications Development > IBM Software Group > > > > -Original Message- > > From: Michael Schout [mailto:mschout@;gkg.net] > > Sent: Tuesday, October 22, 2002 2:00 PM > > To: Christian Gilmore > > Cc: Modperl Mailing List (E-mail) > > Subject: Re: AuthCookie questions > > > > > > Christian Gilmore wrote: > > > > > 4. I cannot modify the cookie and should not send > > additional cookies. > > > > [snip] > > > > > about 4. Can I use an unmodified AuthCookie to ensure that > > whatever format > > > the inbound cookie is in is sufficient and will not need to > > be modified or > > > supplemented? I believe the answer is no, and, if it is, > > should this be > > > > What exactly do you mean by this? What are you trying to accomplish? > > Do you mean "The user cannot modify the cookie?" If thats what you > > mean, then yes, there are ways to do that. Basically you have to > > cryptographically sign the cookie using a secret that is > > unknown to the > > end user. There is an example of this in the Eagle book, and > > Apache::AuthTicket uses a scheme similar to this. Because you cant > > control what the cookie server sends, you'd probably have to do some > > sort of double redirect For example: > > > > o user is redirected to auth server > > o auth server returns cookie and redirects to /SIGNHANDLER > > o signhandler gets the cookie, cryptographically signs it, and > >returns the cookie to the client and redirects to real location > > o user is redirected to real location. > > > > If thats not what you mean, please elaborate. > > > > Regards, > > Mike > > >
Re: serving large files with access controls
We talked about this limiation of the dual setup before. There is no solution publically available. But you can try this: 1) check http://modperl.home.att.net or similar cookie-based ticketing system. 2) write a "ticket-client" module in C and load it into the proxy server (I have one based on libapreqs). 3) you can use the same "ticket issuer" mod_Perl module in the server machine, or any language as far as it can generate a valid cookie. 4) then serve the large file directly via the proxy server. Peter - Original Message - From: "Erik Rantapaa" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, October 13, 2002 12:54 PM Subject: serving large files with access controls > > Suppose I have a typical proxied mod-perl setup and I > have a large (~ 650 MB) file I'd like to provide > authenticated access to. The mod-perl server will be > doing the authentication, but for performance > considerations I'd like the proxy server to serve the > file directly instead of having the mod-perl server > first forward the file to the proxy. > > Is there a way to do this so that access to the file > would be _impossible_ unless the user is authenticated > by the mod-perl server? I am looking for a solution > that can guarantee that there is no way to circumvent > the authentication process. I can think of solutions > where the probability that users can access the file > without authenticating can be made very small, but I > am looking for an absolute guarantee. > > Regards, > > Erik Rantapaa > [EMAIL PROTECTED] > > > __ > Do you Yahoo!? > Faith Hill - Exclusive Performances, Videos & More > http://faith.yahoo.com
Re: UTF8 character issue with Apache::Request?
Please take a serious look. There were several related reports in the mailing list during the months: Apache::Request might not handle double-bytes or utf8 correctly. Or it may be due to the C library. Peter - Original Message - From: "Joe Schaefer" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; "modperl list" <[EMAIL PROTECTED]> Sent: Saturday, September 28, 2002 10:08 AM Subject: Re: UTF8 character issue with Apache::Request? > <[EMAIL PROTECTED]> writes: > > [...] > > > With Kanji filename : > > Size is 0 > > UPL:Content-Disposition=form-data; name="UPLOADFILE"; > > filename=".DOC" > > UPL:Content-Type=application/octet-stream > > > > Without Kanji filename > > Size is 306688 > > UPL:Content-Disposition=form-data; name="UPLOADFILE"; > > filename="copy.DOC" > > UPL:Content-Type=application/msword > > > > Any thoughts or input would be great. > > Are you certain this is a server-side problem? The > varying Content-Types look suspicious to me. I'd double-check > (via tcpdump or something) that the client is actually sending > the whole file to the server. > > -- > Joe Schaefer >
Re: POST problems
I recalled a similar problem sometimes ago. But it is repeatable. One of the form fields went to empty, if other fields contain unicode or double bytes. It might link to escaped characters or unicode in the query string. The form handles uploading using Apache:Request. Peter - Original Message - From: "Anthony Heading" <[EMAIL PROTECTED]> To: "Corey Durward" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Friday, September 20, 2002 2:38 AM Subject: Re: POST problems > On Fri, Sep 20, 2002 at 08:22:11AM +0930, Corey Durward wrote: > > Having a curious problem with the POST command with all CGI scripts on a > > particular server (Apache/1.3.14 (Unix) (Red-Hat/Linux) DAV/1.0.2 PHP/4.0.6 > > mod_perl/1.24). Basically, it doesn't work. Form inputs are treated as > > though the inputs were blank. > > I hit exactly this problem, maybe about six months ago. > > > Everything was working fine up until a few weeks ago. The server admin > > claims nothing has been modified in that time (I'm skeptical) and is > > clueless as to the cause. > > In my case, I found it could be triggered by some mod_perl scripts; > running those left each Apache in a confused state where it lost all > cgi POST params. I was vaguely interested to hunt it down, enough > to collect lots of system call traces and so on, but then pressure of > time led me just to try upgrading everything - to mod_perl 1.26 on > perl 5.6.1 and apache 1.26 or whatever. And the problem went away. > > Anthony > > > This communication is for informational purposes only. It is not intended as > an offer or solicitation for the purchase or sale of any financial instrument > or as an official confirmation of any transaction. All market prices, data > and other information are not warranted as to completeness or accuracy and > are subject to change without notice. Any comments or statements made herein > do not necessarily reflect those of J.P. Morgan Chase & Co., its > subsidiaries and affiliates. > >
Re: performance regarding mod_perl vs mod_c with embedded perl
The linked page is great, especially the first picture. Problem in authentication: if mod_perl returns cached header and the document is proxy cached in the plain Apache, the backend authentication handler (in the mod_perl server) will not be able to protect it. Peter Bi - Original Message - From: "Ask Bjoern Hansen" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: "Josh Chamas" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Wednesday, September 18, 2002 3:36 AM Subject: Re: performance regarding mod_perl vs mod_c with embedded perl > > You don't do that for "raw performance" as measured in a typical > simple benchmark environment. The dual setup is used to not > needlessly waste resources in a "real" setup. > > Raw benchmark numbers will come out a bit lower, but you don't care > as a proper setup will save you LOTS of memory, database connections > and what have you not. > > http://develooper.com/modperl/performance_tuning.html > > (Click "Next" on the top of each slide to progress ... The first few > slides looks weird in Mozilla 1.0 on my Linux box but are fine in > Chimera on Mac OS X - get a Mac! :-) ) > > > - ask > > -- > ask bjoern hansen, http://www.askbjoernhansen.com/ !try; do(); >
Re: mod_perl & mod_php
On 29 Aug 2002 at 19:47, Jesse Erlbaum wrote: > I notice that you are using mod_perl AND mod_php. > > I have a general question for the list: Do people often use BOTH of > these environments at the same time? It seems to me that there would be > little benefit to using both. Am I mistaken? Most people on this list, it seems, work on rather large sites where they have at least ONE server. I work on small mom-and-pop sites which run on virtual servers. PHP is far, far easier to deploy on these ubiquitous virtual servers. I have in fact moved my apps from mod_perl because the market is just not there if your audience is mom-and-pop (ymmv). This is my primary server: > Apache/1.3.26 OpenSSL/0.9.6g (Unix) ApacheJServ/1.1 mod_perl/1.21 > PHP/4.0.6 BTW, since someone asked about PHP code, I have been doing a lot of work in PHP lately. I took over for some Russian programmers on one project no comments, none, at least 100 php files throughout the site, proprietary templating system, scope is not by file but by site :) And I've been working on jawamail and that's quite fun. I would much rather work on code written by others in Perl than what I see in PHP. Most of the PHP reminds me of the older Perl4 style where a programmer might repeat the same code very 20 lines :) But there are some good things written in PHP, it's just that there are a WHOLE lot more people writing PHP than Perl (just look at the mailing lists and script archives). Peter --- "Reality is that which, when you stop believing in it, doesn't go away". -- Philip K. Dick
Re: odd authetication situation
Maybe you can try to add specifically:
$r->connection->user('who_the_user_is') before the cookie access control
returns OK in the module. Note that some of the cookie authentication
modules are based on "access-only" control so $r->connection->user() can
return a value in late phases only if one assigns it at the first place.
Peter Bi
- Original Message -
From: "Michael Robinton" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, August 28, 2002 1:05 PM
Subject: odd authetication situation
>
> I have a modperl handler that sets a cookie and does a redirect if the
> cookie was not present. The redirected page eventually loads the same page
> again. In addition, this page is called from a protected portion of the
> site that requires Basic Auth.
>
> When the redirect calls the mod_perl routine the second or "some"
> subsequent times, $r->connection->user and $ENV{REMOTE_USER} are both
> empty or non-existent yet the page does not appear to fail the
> authentication request and executes and returns html.
>
> The failure is repeatable though not consistently so, maybe 70% or more.
>
> I'm scratching my head on this one. Any ideas??
>
> Michael
>
>
Re: large projects in mod_perl
How about application software ? The lists are either programming tools or language iteself. I mean something like ... online accounting software ... just for example. Peter Bi - Original Message - From: "Per Einar Ellefsen" <[EMAIL PROTECTED]> To: "zt.zamosc.tpsa.pl" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Tuesday, August 27, 2002 12:43 AM Subject: Re: large projects in mod_perl > At 09:16 27.08.2002, zt.zamosc.tpsa.pl wrote: > >Hi all > > > >Does anyone know where I can find some information on creating big projects > >in Perl (mod_perl)? > >I am facing the really big project now but I don't know what stucture of the > >program will be the best. > > > >There are such things like Struts, jBoss in Java. What about Perl? > > Well, with mod_perl you have many possibilities. I would advise you to read > http://perl.apache.org/docs/tutorials/apps/scale_etoys/etoys.html for an > explanation about a big project involving mod_perl at EToys, and > http://perl.apache.org/products/app-server.html for a list of application > servers available for mod_perl (as well as maybe > http://perl.apache.org/docs/tutorials/tmpl/comparison/comparison.html to > look at how to choose a templating system). > > You might also want to develop your own architecture based on MVC, which we > had a long discussion about here recently. For a lot of interesting > reading, look at these threads: > o http://mathforum.org/epigone/modperl/jilgygland > o http://mathforum.org/epigone/modperl/pahphucree > o http://mathforum.org/epigone/modperl/solchaxzim > o http://mathforum.org/epigone/modperl/lerdginspir > o http://mathforum.org/epigone/modperl/stremnemcland > o http://mathforum.org/epigone/modperl/nounumspim > o http://mathforum.org/epigone/modperl/blildeudrand > o http://mathforum.org/epigone/modperl/zhathontimp > o http://mathforum.org/epigone/modperl/drehkrerlnen > o http://mathforum.org/epigone/modperl/drurflerdplald > > > -- > Per Einar Ellefsen > [EMAIL PROTECTED] > > >
Re: Apache::Session - What goes in session?
On 21 Aug 2002 at 2:09, Ask Bjoern Hansen wrote:
> Now using good old Fcntl to control access to simple "flat files".
> (Data serialized with pack("N*", ...); I don't think anything beats
> "pack" and "unpack" for serializing data).
>
> The expiration went into the data and purging the cache was a simple
> cronjob to find files older than a few minutes and deleting them.
>
> The performance? I don't remember the exact figure, but it was at
> least several times faster than the BerkeleyDB system. And *much*
> simpler.
>
>
> The morale of the story: Flat files rock! ;-)
If I'm using Apache::DBI so I have a persistent connection to MySQL,
would it not be faster to simply use a table in MySQL?
Peter
---
"Reality is that which, when you stop believing in it, doesn't go
away".
-- Philip K. Dick
Re: NTLM module
Adam: Netscape does behave somehow differently under the authentication. I used to have similar problem with a Perl authen module using Netscape 6 (Netscape 4.0 and 3.0 are okay, however). It looks like N6 uses more caching, and does not tolerate any departure from the httpd 1.1 definition; so one gets often the same pop-up login page instead of the redirected page. You may try to remove any caching tags and add nocache in the code. Peter - Original Message - From: "Kaye-Smith Adam" <[EMAIL PROTECTED]> To: "Gerald Richter" <[EMAIL PROTECTED]>; "Peter Bi" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Monday, August 19, 2002 9:46 PM Subject: RE: NTLM module I am still having problems with the AuthenNTLM module. All works fine for IE and Mozilla browsers but when I use Netscape, I am repeatedly promted for passwords. If I enter my password about 3 to 6 times I will eventually get the full page . If I enter password once, ( and cancel for any further password prompts ) I get only bit of the expected page. If I put a sleep (2) in the perl module before it goes to verify against the SMB server, netscape browser will work albeit somewhat slower. The other aspect I can not understand is that when the perl NTLM module is running, it will often exit from sub's other than the handler sub. ie the handler sub is always called first which calls other sub's but whilst executing these other sub''s , it appears that something seems to cut processing short & passes control back to apache - the perl code never gets a chance to return to the handler module & exit code with a 'return xx'. I have been observing the perl's progress by looking at entries in the error.log . I have also put in a variety of print STDERR staements at key positions to see where the code is exiting. If for instance I put a sleep command in the perl module, the code will often exit whilst the sleep is taking place - it appears that the NTLM module has run out of its allowed time and it has been cut short. The other conclusion is that multiple threads are running and outputting to the error.log & confusing me with the overlapping output. This strange exiting behaviour also appears to occur on all browsers (once that work ok & netscape that does not work.) The other error I get is that the username/password is passed ok from the SMB server verification phase, but then in subsequent calls to the SMB server, the username/password fails - this occurs during the one entry of username/password but the SMB server is contacted several times for verification ( I also check the username & password in the script before thay are submitted to the SMB server so I know they are correct.) Would this be because of timeout in the SMB to respond. I would also expect the SMB server to only need to referred to once, but the perl module is calling the SMB module 3 times during the one username/password entry. I hope the above make sense. I can my log file if this would help. Regards Adam -Original Message- From: Kaye-Smith Adam Sent: Monday, 19 August 2002 9:15 AM To: 'Gerald Richter'; Peter Bi; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: NTLM module Thanks for your advice Gerald. I have found a compromise buy having the directive of Authtype Basic but the perl code has been changed to run the NTLM check as well as SMB (regardlesss of the config file) and if both authentications fail, the standard mod_auth code will then be run. Thanks once again. Adam The information in this e-mail together with any attachments is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any form of review, disclosure, modification, distribution and/or publication of this e-mail message is prohibited. If you have received this message in error, you are asked to inform the sender as quickly as possible and delete this message and any copies of this message from your computer and/or your computer system network.
Re: NTLM module
Gerald: Any comment on Paulo's question ? (I am interested in that knowledge too.) I doubt that NTLM does not need any password. Logically, there must be a way to set up the initial trustful connection between two machines. If not password, what will that be ? Or something like Digital Authentication ? Peter - Original Message - From: <[EMAIL PROTECTED]> To: "Peter Bi" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Tuesday, August 13, 2002 2:36 PM Subject: Re: NTLM module > Am I totally wrong, or the plain and painful answer is > that "NTLM is only supported on Win32 boxes"? I think > I read somewhere that, because the module relies the > Win32 API, it doesn't run on other systems. It even > said something like "...whoever wants to grab some > Samba code and port the module to *nix, please do...". > > Again, this is just "something I guess I think I read > somewhere", so take it with a grain of salt. > > Paulo Meireles > MCSE (and not ashame of it) > ;-) > > > Como Reduzir os Riscos de Segurança da Sua Organização Whitepaper Gratuito sobre Serviços > de Segurança http://www.vianetworks.pt/security/whitepaper_f&s.html > > and - Original Message - From: "Gerald Richter" <[EMAIL PROTECTED]> To: "Peter Bi" <[EMAIL PROTECTED]>; "Kaye-Smith Adam" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Tuesday, August 13, 2002 8:58 PM Subject: Re: NTLM module > > > > The username/password pair is sent only once to the issuer machine and the > > follow-up authentications are performed using a self-certified, > > time-limited, hash. In fact, it is based on access-control, having nothing > > to do with Basic Authentication. This is discussed in detail in the Eagle > > book. I am not sure if NTLM is even better but for most applications, it > is > > pretty secure. > > > > NTLM is a bit more secure, but also this is not the point here. NTLM auth > doesn't require you to enter your password at all. I don't argue that NTLM > is better, it just fits better in some intranet situations, because the user > doesn't have to type in the username/password. > > It's seems that I was not clear enough. The only thing I say is that under > the precondition you want to use NTLM client authetication, you can't use > the way your module verifies the password. > > Gerald > > - > Gerald Richterecos electronic communication services gmbh > Internetconnect * Webserver/-design/-datenbanken * Consulting > > Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz > E-Mail: [EMAIL PROTECTED] Voice:+49 6133 925131 > WWW:http://www.ecos.de Fax: +49 6133 925152 > - > > > Peter > > > > - Original Message - > > From: "Gerald Richter" <[EMAIL PROTECTED]> > > To: "Peter Bi" <[EMAIL PROTECTED]>; "Kaye-Smith Adam" > > <[EMAIL PROTECTED]> > > Cc: <[EMAIL PROTECTED]> > > Sent: Tuesday, August 13, 2002 12:29 PM > > Subject: Re: NTLM module > > > > > > > > > > > > if you check the source of the Smb implemenation of the module, you > > would > > > > see that it performs basically the same function as NTLM. I agree with > > you > > > > that it does not fit the Microsoft definition of NTLM, so it is not a > > NTLM > > > > implementation. If ones purpose is to pass the protection by providing > a > > > > valid username/password pair in a NT domain, then one does not have to > > > > follow that definition and the current Smb implementation is one of > the > > > > possible solutions. > > > > > > > > > > The point is not how the password is passed to the nt server, the point > is > > > how the browser and the web server exchange the credenticals. With basic > > > auth and with your module the user enters a username and a password and > > you > > > use different backends to verify this. With NTLM authentication the > > Internet > > > Exploerer and the Web server uses a challange-response procdure to > > exchange > > > credenticals (and IE does this without asking the user, so you get > logged > > on > > > with your windows username, which safes the user some extra typing). > They > > > never send the password over the wire, so you don't have a pa
Re: NTLM module
The username/password pair is sent only once to the issuer machine and the follow-up authentications are performed using a self-certified, time-limited, hash. In fact, it is based on access-control, having nothing to do with Basic Authentication. This is discussed in detail in the Eagle book. I am not sure if NTLM is even better but for most applications, it is pretty secure. Peter - Original Message - From: "Gerald Richter" <[EMAIL PROTECTED]> To: "Peter Bi" <[EMAIL PROTECTED]>; "Kaye-Smith Adam" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Tuesday, August 13, 2002 12:29 PM Subject: Re: NTLM module > > > > if you check the source of the Smb implemenation of the module, you would > > see that it performs basically the same function as NTLM. I agree with you > > that it does not fit the Microsoft definition of NTLM, so it is not a NTLM > > implementation. If ones purpose is to pass the protection by providing a > > valid username/password pair in a NT domain, then one does not have to > > follow that definition and the current Smb implementation is one of the > > possible solutions. > > > > The point is not how the password is passed to the nt server, the point is > how the browser and the web server exchange the credenticals. With basic > auth and with your module the user enters a username and a password and you > use different backends to verify this. With NTLM authentication the Internet > Exploerer and the Web server uses a challange-response procdure to exchange > credenticals (and IE does this without asking the user, so you get logged on > with your windows username, which safes the user some extra typing). They > never send the password over the wire, so you don't have a password to > send/verify to your backend. > > What you talking about is the verification of the password between the web > server and the nt domain controller, thats something different. > > Gerald > > > > > > Peter > > > > - Original Message - > > From: "Gerald Richter" <[EMAIL PROTECTED]> > > To: "Peter Bi" <[EMAIL PROTECTED]>; "Kaye-Smith Adam" > > <[EMAIL PROTECTED]> > > Cc: <[EMAIL PROTECTED]> > > Sent: Tuesday, August 13, 2002 12:53 AM > > Subject: Re: NTLM module > > > > > > > > > > > > > > You may check Apache::Access module at http://modperl.home.att.net in > > > which > > > > I tried to provide a general solution to several popular > authentication > > > > issuers such as SMB, LDAP, IMAP, NIS, FTP, LWP and DBI etc. > > > > > > > > > > I think you missed the point (or I missunderstood your module): The > > problem > > > is not doing the authentication against whatever, but doing NTLM > > > authetication. With NTLM auth you don't get a password from the client, > so > > > how would compare the password that you don't have against "SMB, LDAP, > > IMAP, > > > NIS, FTP, LWP and DBI etc." ? > > > > > > The only solution is to reimplement the challage/response that NTLM > does. > > > (The module Authen::Perl::NTLM maybe helpfull here). To do this you need > > > either the password in clear text to compute the nt password hash (a > sort > > of > > > md4 hash) or the precomputed nt password hash. You won't have this with > > > LDAP, IMAP, NIS, FTP, LWP and DBI etc > > > > > > Gerald > > > > > > - > > > Gerald Richterecos electronic communication services gmbh > > > Internetconnect * Webserver/-design/-datenbanken * Consulting > > > > > > Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz > > > E-Mail: [EMAIL PROTECTED] Voice:+49 6133 925131 > > > WWW:http://www.ecos.de Fax: +49 6133 925152 > > > - > > > > > > > > > > Cheers. > > > > > > > > > > > > Peter Bi > > > > > > > > - Original Message - > > > > From: "Gerald Richter" <[EMAIL PROTECTED]> > > > > To: "Kaye-Smith Adam" <[EMAIL PROTECTED]> > > > > Cc: <[EMAIL PROTECTED]> > > > > Sent: Monday, August 12, 2002 9:12 PM > > > > Subject: Re: NTLM module > > > > > > > > > > > > > > > > > > >Acco
Re: NTLM module
Gerald: if you check the source of the Smb implemenation of the module, you would see that it performs basically the same function as NTLM. I agree with you that it does not fit the Microsoft definition of NTLM, so it is not a NTLM implementation. If ones purpose is to pass the protection by providing a valid username/password pair in a NT domain, then one does not have to follow that definition and the current Smb implementation is one of the possible solutions. Peter - Original Message - From: "Gerald Richter" <[EMAIL PROTECTED]> To: "Peter Bi" <[EMAIL PROTECTED]>; "Kaye-Smith Adam" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Tuesday, August 13, 2002 12:53 AM Subject: Re: NTLM module > > > > You may check Apache::Access module at http://modperl.home.att.net in > which > > I tried to provide a general solution to several popular authentication > > issuers such as SMB, LDAP, IMAP, NIS, FTP, LWP and DBI etc. > > > > I think you missed the point (or I missunderstood your module): The problem > is not doing the authentication against whatever, but doing NTLM > authetication. With NTLM auth you don't get a password from the client, so > how would compare the password that you don't have against "SMB, LDAP, IMAP, > NIS, FTP, LWP and DBI etc." ? > > The only solution is to reimplement the challage/response that NTLM does. > (The module Authen::Perl::NTLM maybe helpfull here). To do this you need > either the password in clear text to compute the nt password hash (a sort of > md4 hash) or the precomputed nt password hash. You won't have this with > LDAP, IMAP, NIS, FTP, LWP and DBI etc > > Gerald > > - > Gerald Richterecos electronic communication services gmbh > Internetconnect * Webserver/-design/-datenbanken * Consulting > > Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz > E-Mail: [EMAIL PROTECTED] Voice: +49 6133 925131 > WWW:http://www.ecos.de Fax: +49 6133 925152 > - > > > > Cheers. > > > > > > Peter Bi > > > > - Original Message - > > From: "Gerald Richter" <[EMAIL PROTECTED]> > > To: "Kaye-Smith Adam" <[EMAIL PROTECTED]> > > Cc: <[EMAIL PROTECTED]> > > Sent: Monday, August 12, 2002 9:12 PM > > Subject: Re: NTLM module > > > > > > > > > > >According to the documentation, if you set NTMLauthoritative to off, > > > >then if NTLM authorization fails, then it should pass it on to the > lower > > > >level modules. > > > > > > Yes, that's true and it works like you describe it. The point that you > are > > > missing is (and that I have tried to show in my last mail), that during > > NTLM > > > authentication there is no password! NTLM never passes the password to > the > > > server, so also the control gets passed to the lower level module, this > > > lower level module must be able to handle NTLM. The default Apache auth > > > handler isn't able to do so. It expects a password, which it doesn't > gets > > > because the client never has send it. > > > > > > Hope it's a little bit more clear now > > > > > > Gerald > > > > > > - > > > Gerald Richterecos electronic communication services gmbh > > > Internetconnect * Webserver/-design/-datenbanken * Consulting > > > > > > Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz > > > E-Mail: [EMAIL PROTECTED] Voice:+49 6133 925131 > > > WWW:http://www.ecos.de Fax: +49 6133 925152 > > > - > > > > > > > > > > > > I have cut out the below section from the doco which > > > relates to the above functionality : > > > " > > > =head2 PerlSetVar ntlmauthoritative > > > > > > Setting the ntlmauthoritative directive explicitly to 'off' allows > > > authentication > > > to be passed on to lower level modules if AuthenNTLM cannot autheticate > > > the userand the NTLM authentication scheme is used. > > > If set to 'on', which is the default, AuthenNTLM will try to verify the > > > user andif it fails will give an Authorization Required reply. > > > > > > =head2 PerlSetVar basicautho
Re: NTLM module
You may check Apache::Access module at http://modperl.home.att.net in which I tried to provide a general solution to several popular authentication issuers such as SMB, LDAP, IMAP, NIS, FTP, LWP and DBI etc. Cheers. Peter Bi - Original Message - From: "Gerald Richter" <[EMAIL PROTECTED]> To: "Kaye-Smith Adam" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Monday, August 12, 2002 9:12 PM Subject: Re: NTLM module > > >According to the documentation, if you set NTMLauthoritative to off, > >then if NTLM authorization fails, then it should pass it on to the lower > >level modules. > > Yes, that's true and it works like you describe it. The point that you are > missing is (and that I have tried to show in my last mail), that during NTLM > authentication there is no password! NTLM never passes the password to the > server, so also the control gets passed to the lower level module, this > lower level module must be able to handle NTLM. The default Apache auth > handler isn't able to do so. It expects a password, which it doesn't gets > because the client never has send it. > > Hope it's a little bit more clear now > > Gerald > > - > Gerald Richterecos electronic communication services gmbh > Internetconnect * Webserver/-design/-datenbanken * Consulting > > Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz > E-Mail: [EMAIL PROTECTED] Voice:+49 6133 925131 > WWW:http://www.ecos.de Fax: +49 6133 925152 > - > > > > I have cut out the below section from the doco which > relates to the above functionality : > " > =head2 PerlSetVar ntlmauthoritative > > Setting the ntlmauthoritative directive explicitly to 'off' allows > authentication > to be passed on to lower level modules if AuthenNTLM cannot autheticate > the userand the NTLM authentication scheme is used. > If set to 'on', which is the default, AuthenNTLM will try to verify the > user andif it fails will give an Authorization Required reply. > > =head2 PerlSetVar basicauthoritative > > Setting the ntlmauthoritative directive explicitly to 'off' allows > authentication > to be passed on to lower level modules if AuthenNTLM cannot autheticate > the userand the Basic authentication scheme is used. > If set to 'on', which is the default, AuthenNTLM will try to verify the > user andif it fails will give an Authorization Required reply. > " > > > > From the above description, I am hoping for the following events to take > place > > > - ntlm authentication (if fail this level go to next authentication) > > - basic authentication (if fails this level go to other > authentication systems) > > - read passwords in htpasswd file ( if this fails, then access not > granted) > > > > > To enable the following behaviour, I have included the following > directives in httpd.conf. > > - ntlmauthoritative off > - basicauthoritative off > > > I have also taken out the basic authentication to see if this works ie > > Authtype ntlm (not basic) > > But this still does fail & allow the htpasswd system to verify access. > > > > If there are changes that need to be made to the AuthenNTLM.pm, I am > not very well read in this area - are there any goof references. > > From my novice perspective, it appears that when NTLM is included as > part of the authentication, the ability for normal modules to verify > access (ie htpasswd file) is no longer available ie the perl module does > not pass back what the standard modules are expecting. > > I am sorry to be a bit unclear in my analysis, but I am fairly new to > apache & perl modules. > > > Many Thanks > > > Adam > > > original email attached > > > > > > > > > > -Original Message- > From: Gerald Richter [mailto:[EMAIL PROTECTED]] > Sent: Monday, 12 August 2002 5:35 PM > To: Kaye-Smith Adam; [EMAIL PROTECTED] > Subject: Re: NTLM module > > > > - Original Message - > From: "Kaye-Smith Adam" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Monday, August 12, 2002 4:51 AM > Subject: NTLM module > > > Hello , > > > >When I enter in an NT password it all works ok but when I use a > >user/pass from the htpasswd file, the only way it will work is that I > >change the above line to > > > >AuthType Basic instead of > >AuthType ntlm,Basic. > > > > &
Re: Is it possible to change the browser's address/location URL without Redirect?
It is the browser that controls the URL in the "Address" bar. So one has to
make another call to get the URL refreshed. If you are worry about the
speed, you may
1) return an error code in case of error
2) in Apache's httpd.conf, config that specific error to display
/step/1/error
A simply redirection does the same job.
Peter
- Original Message -
From: "Harry Zhu" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, August 09, 2002 11:26 AM
Subject: Is it possible to change the browser's address/location URL without
Redirect?
> Looks like my explanation is too long or too bad.
> The simple idea is in page step 1, after the
>
> ...
>
> submitted, I want the browser show something
> http://www.example.com/step/1/error, instead of
> http://www.example.com/step/2,
> if there is a need for user to correct the data submitted.
>
> It might be accomplished by using one of the approaches outlined below,
but
> I was wondering if there's other way that can save the overhead of the
> write/read or resend the data, and the re-process. Probably not much we
can
> do if the URL displayed in the browser's address/location bar depends only
> on the action value of the form submitted, not based on the server
response?
>
> Harry
>
>
>
> - Original Message -
> From: "Harry Zhu" <[EMAIL PROTECTED]>
> To: "mod_perl list" <[EMAIL PROTECTED]>
> Sent: Thursday, August 08, 2002 4:22 PM
> Subject: Can I change the browser's address/location?
>
>
> > Suppose I have a generic content handler to handle requst
> > /step/1, /step/2, ..., /step/n
> >
> >
> > SetHandler perl-script
> > PerlHandler MyHandler
> >
> >
> >
> > #MyHandler.pm
> > package MyHandler;
> > sub handler {
> > my $r=shift;
> > my $step = substr($r->path_info(),1);
> >
> > #do something before fetch the content
> >
> > #fetch content: usually include a form that will assign action
> > /step/($step+1)
> >
> > }
> >
> > So if everything goes well, the user will follow through from step 1,
step
> > 2, until fnish.
> > Now if in the "#do something ..." part, something is wrong, it will
> usually
> > require user go back to the same step, for example, to fill the form
> again.
> > The way my old cgi script does is just generate the form with prefilled
> > value plus some error message indicate what's wrong. It works ok but the
> > browser location will show /step/($step+1) while it actually is
> /step/$step.
> > Now that I am working it on mod-perl I thought I should be able to do
> > something about it. I briefly browsed the 2 mod-perl books (eagle,
> > cookbook), and could not found a simple solution yet (or I missed it?).
I
> > was think using one of the folowing might work:z
> > 1) save the request data in a temp file and redirect or http-refresh to
> > /step/$step?$session_id or /step/$step/error?$session_id
> > Remember the content is dynamic and depend on the input form data, so
> simple
> > redirect may not work.
> > Looks like Apache will not post the form data when redirect with
Location?
> >
> > 2) print a short form with hidden data and assign
action=/step/$step/error
> > then submit right away (onload=form.submit()?)
> >
> > Does anybody have a simple solution, e.g. without redirect? Is it
possible
> > to change the URI showing in the browser's address/location bar?
> >
> > I would appreciated if somebody can pointer me to the right direction.
> >
> > Harry
> >
> >
>
>
RE: How to see debug information in Net::Smtp?
its bitten me in the ass a few times before, just thought id mention it cheers -pete -Original Message- From: Stas Bekman [mailto:[EMAIL PROTECTED]] Sent: Wednesday, July 17, 2002 1:29 PM To: Peter Werner Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: How to see debug information in Net::Smtp? Peter Werner wrote: > and set your LogLevel to debug why? after all he is talking about perl logging, not Apache. LogLevel has nothing to do with it. > -Original Message- > From: Stas Bekman [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, July 17, 2002 10:27 AM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: Re: How to see debug information in Net::Smtp? > > > [EMAIL PROTECTED] wrote: > >>I use Net::Smtp module in my mod_perl script. When I run the >>fragment of my code from command line I can see the debug info. >>But running it on the production server I can't see the debug >>information. >> >>What can I do to see the debug info on the production server? > > > look in the error_log file? > > > > __ > Stas BekmanJAm_pH --> Just Another mod_perl Hacker > http://stason.org/ mod_perl Guide ---> http://perl.apache.org > mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com > http://modperlbook.org http://apache.org http://ticketmaster.com -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
RE: How to see debug information in Net::Smtp?
and set your LogLevel to debug -Original Message- From: Stas Bekman [mailto:[EMAIL PROTECTED]] Sent: Wednesday, July 17, 2002 10:27 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: How to see debug information in Net::Smtp? [EMAIL PROTECTED] wrote: > I use Net::Smtp module in my mod_perl script. When I run the > fragment of my code from command line I can see the debug info. > But running it on the production server I can't see the debug > information. > > What can I do to see the debug info on the production server? look in the error_log file? __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
RE: mod_perl help
make sure you are not using the sun as and ld etc. you can check by looking at the output of "which as". (should be /usr/local/bin/as not /usr/ccs/bin/as). i have /usr/local/bin in my PATH before /usr/ccs/bin and /usr/ucb. if this doesnt help i would try recompiling perl. maybe someone with more knowledge of the subject could explain why mod_perl needs perl to be compiled with the same compiler (just idle curiosity) cheers -pete -Original Message- From: Ryan Hairyes [mailto:[EMAIL PROTECTED]] Sent: Thursday, July 11, 2002 4:45 PM To: Peter Werner Cc: [EMAIL PROTECTED] Subject: RE: mod_perl help Thanks for the reply. Actually ... according to sunfreeware perl5.6.1 was compiled with gcc. Anything else you can think of? Thanks again. Quoting Peter Werner <[EMAIL PROTECTED]>: : you will have to compile perl from scratch as the sunfreeware perl is : compiled with suns compiler not gcc and this causes problems. poke around : sunfreeware.com for the instructions he used to build perl, it is quite : simple. : : -pete : : -Original Message- : From: Ryan Hairyes [mailto:[EMAIL PROTECTED]] : Sent: Thursday, July 11, 2002 4:34 PM : To: [EMAIL PROTECTED] : Subject: mod_perl help : : : Hello all, : : I just compiled mod_perl 1.27 with apache 1.3 for Solaris 8. I used perl : 5.6.1 and gcc from www.sunfreeware.com. After I compiled everything and : tried : to load the perl module (with LoadModule) I receive the following error: : : : Cannot load /usr/local/apache/libexec/libperl.so into server: ld.so.1: : /usr/local/apache/sbin/httpd: fatal: relocation error: file : /usr/local/apache/libexec/libperl.so: symbol main: referenced symbol not : found : : : Any idea on what I did wrong? Thanks. : : Ryan : -- Ryan Hairyes Network/System Administration Lee County School System Phone:919.774.6226 x 1252 Voicemail:x 2361
Re: [mod_perl2] PerlChildInitHandlers with multiple (Win32) threads
Thanks for the info, its exactly what I needed. -pete Stas Bekman wrote: > Peter Rothermel wrote: > > Stas Bekman wrote: > > > > > >>Peter Rothermel wrote: > >> > >> > >>>PerlChildInitHandler Apache::foo->loadkey > >>> > >>>Will the genkey method get execute at the > >>>initialization of each thread? > >> > >>Apache doesn't provide such a hook yet. May be in the future. > >> > >>child_init is for child process init, not threads. > >>>http://perl.apache.org/release/docs/2.0/user/handlers/handlers.html#PerlChildInitHandler > >> > >>what are you trying to do? > > > > > > I'm encrypting/decrypting data within cookies that are holding session keys > > for authentication purposes. I decrypt the session key within the cookie data, > > whenever I get an http request that has a cookie in the header. > > > > The RSA keys that I use for encrytion/decryption are regenerated when the Apache > > server is started. My module has a load_key subroutine that I call before I do any > > encryption or decryption. This returns a RSA object that is initialized with a >global > > var that hold a 2048 bit RSA key. If the global var is empty I generate a new key. > > > > The code works OK but I seem to be generating a 2048 bit key the first time > > that a user logs into my site. This key generation takes awhile. I would prefer > > generating the key when server/thread/interupter is started. I was hoping that > > a PerlClhildInitHandler could be used to call the gen_key subroutine to load > > the data into global var $private_key_string. > > There are a few possible approaches to this: > > 1. for mod_perl to provide hooks for the following events: > interp_init (INIT) > interp_destroy(DESTROY) > so these can be run when a new interpreter is initialized after it has > been cloned and when it's going to be destroyed. > > 2. Using the thread interpreter pool mechanism for managing other items. > But it's not clear whether this interface will ever have a Perl API, > because threads::shared already does that. > > 3. Build a pool based on threads::shared. Similar to what Doug has > described in his overview: > >http://perl.apache.org/release/docs/2.0/user/overview/overview.html#Thread_Item_Pool_API > and which is now doable in pure Perl based on threads::shared. This is > an interesting vacant module, but really you can just duplicate the > concepts that Doug has described in the URL above. You want to be able > to add new items, remove them, pop and push from the pool. > > should it be called Threads::TIPool as coined by Doug? (Thread Items Pool) > > Using this (currently not-existing) module you can create a pool of keys > at the server startup and then use them whenever you need a key at run time. > > This is the same concept that the threaded version of Apache::DBI is > going to use, and AFAIK is vacant as well. The challenge is to make it > possible to have modules like Apache::DBI work transparently under > various mpms, including the preforked and perchild mpms. > > __ > Stas BekmanJAm_pH --> Just Another mod_perl Hacker > http://stason.org/ mod_perl Guide ---> http://perl.apache.org > mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com > http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mod_perl2] PerlChildInitHandlers with multiple (Win32) threads
David Dyer-Bennet wrote: > Peter Rothermel <[EMAIL PROTECTED]> writes: > > > Stas Bekman wrote: > > > > > Peter Rothermel wrote: > > > > > > > > > > > PerlChildInitHandler Apache::foo->loadkey > > > > > > > > Will the genkey method get execute at the > > > > initialization of each thread? > > > > > > Apache doesn't provide such a hook yet. May be in the future. > > > > > > child_init is for child process init, not threads. > > > >http://perl.apache.org/release/docs/2.0/user/handlers/handlers.html#PerlChildInitHandler > > > > > > what are you trying to do? > > > > I'm encrypting/decrypting data within cookies that are holding session keys > > for authentication purposes. I decrypt the session key within the cookie data, > > whenever I get an http request that has a cookie in the header. > > What's the benefit of encrypting the session keys in the cookie? If > they're randomly chosen from a very large space, the probability of > guessing a valid session key can be made exactly equal to the > probability of guessing the encryption key. > I am using the term "session key" in the context of the the Apache::AuthCookie module that is maintained by Michael Schout. In my system, the session key holds some group membership and access rights information that is returned by an authentication server when the user provides credentials (username, password,..) via a login page. The session key is not very large or randomly selected. > > In particular, if the *result* of the encryption is, say, a 32-bit > encrypted session key, is that any more secure than simply picking a > random 32-bit session key to begin with? Even with a 2048-bit > encryption key, there are actually only 32 bits of space to search for > a hit. (So you don't need to have a 2048-bit session key space to > match the security of a 2048-bit encryption key applied to a 32-bit > session key space; a 32-bit session key space alone is just as safe.) > > And of course the key generation, encryption, and decryption take CPU > power, *and* require additional code that could have bugs, which could > be security problems. > > I've seen people (including one client) *very* committed to this > "encrypted session key" concept before, and I've never been able to > understand what benefit it buys them. I ask because I'm NOT yet > totally convinced I'm right; though I'm convinced enough that the > sites I design depend on it. > > (One obvious answer is "there are big wins for us in having session > keys that *aren't* randomly chosen"). > -- > David Dyer-Bennet, [EMAIL PROTECTED] / New TMDA anti-spam in test > John Dyer-Bennet 1915-2002 Memorial Site http://john.dyer-bennet.net > Book log: http://www.dd-b.net/dd-b/Ouroboros/booknotes/ > New Dragaera mailing lists, see http://dragaera.info
Re: [mod_perl2] PerlChildInitHandlers with multiple (Win32) threads
Stas Bekman wrote:
> Peter Rothermel wrote:
>
> >
> > PerlChildInitHandler Apache::foo->loadkey
> >
> > Will the genkey method get execute at the
> > initialization of each thread?
>
> Apache doesn't provide such a hook yet. May be in the future.
>
> child_init is for child process init, not threads.
>
>http://perl.apache.org/release/docs/2.0/user/handlers/handlers.html#PerlChildInitHandler
>
> what are you trying to do?
I'm encrypting/decrypting data within cookies that are holding session keys
for authentication purposes. I decrypt the session key within the cookie data,
whenever I get an http request that has a cookie in the header.
The RSA keys that I use for encrytion/decryption are regenerated when the Apache
server is started. My module has a load_key subroutine that I call before I do any
encryption or decryption. This returns a RSA object that is initialized with a global
var that hold a 2048 bit RSA key. If the global var is empty I generate a new key.
The code works OK but I seem to be generating a 2048 bit key the first time
that a user logs into my site. This key generation takes awhile. I would prefer
generating the key when server/thread/interupter is started. I was hoping that
a PerlClhildInitHandler could be used to call the gen_key subroutine to load
the data into global var $private_key_string.
my $self = shift;use vars qw($VERSION $private_key_string @ISA);
sub gen_key : method {
my ($self,$r) = @_;
my $rlog = $r->log;
my $tmprsa = Crypt::OpenSSL::RSA->new();
$rlog->notice("Generating a RSA key");
$tmprsa->generate_key(2048);
$private_key_string = $tmprsa->get_private_key_string();
}
sub load_key : method {
my ($self,$r) = @_;
my $rlog = $r->log;
my $rsa;
if (length($private_key_string)) {
$rsa = Crypt::OpenSSL::RSA->new();
$rsa->load_private_key( $private_key_string );
}
else {
$rsa = $self->gen_key;
}
return $rsa;
}
>
>
> You should try to write your code in mpm-agnostic way if possible. so
> the same code can run under various mpms.
>
> __
> Stas BekmanJAm_pH --> Just Another mod_perl Hacker
> http://stason.org/ mod_perl Guide ---> http://perl.apache.org
> mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
> http://modperlbook.org http://apache.org http://ticketmaster.com
[mod_perl2] PerlChildInitHandlers with multiple (Win32) threads
greetings, I'm looking for the documentation that describes how PerlChildInitHandlers work with multiple threads on Win32 platforms. Here's a specific question: I have the following in my httpd.conf: ThreadsPerChild 10 MaxRequestsPerChild 0 PerlChildInitHandler Apache::foo->genkey Will the genkey method get execute at the initialization of each thread? -pete
Re: [OT] Better Linux server platform: Redhat or SuSe?
Maybe that depends on the project. We have a powerful BBS system, which contains: read/post messages, public and member sign ups, messages cached to disk or memory, email notification, fast sorting of message threads and follow-ups, and a number of other features. It consists of 5 modules and each module has only 100 - 300 lines. Well, we use HTML::Template that helps to separate the HTML codes from the modules. Having HTML in perl programs makes a big difference. Peter Bi - Original Message - From: "Owen Scott Medd" <[EMAIL PROTECTED]> To: "Peter Haworth" <[EMAIL PROTECTED]> Cc: "Jean-Michel Hiver" <[EMAIL PROTECTED]>; "Gerd Knops" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Wednesday, July 03, 2002 11:53 AM Subject: Re: [OT] Better Linux server platform: Redhat or SuSe? > lol... We're running a little over 175000 lines of (mod)perl code, > currently running on a mix of RedHat 7.1, 7.2, 7.3 and Advanced Server. > > Next? > > On Wed, 2002-07-03 at 09:41, Peter Haworth wrote: > > On Wed, 3 Jul 2002 11:40:44 +0100, Jean-Michel Hiver wrote: > > > > perl: Any iussues with perl/modperl? Besides modperl I will be running a > > > > perl application with a few hundred thousend lines of code... > > > > > > Wow. For reference last time I looked at slashcode it was about 25.000 > > > lines I think. I wonder what kind of application would require more than > > > that amount of Perl code :-) > > > > I'm sure someone else will post a bigger number, but my application (IOP > > Electronic Journals) has 55000 lines of code (including the odd blank line > > and comment, of course). And we're always adding new stuff, so it only ever > > gets bigger. > > > > -- > > Peter Haworth [EMAIL PROTECTED] > > "We don't care how they do it in New York." > > > > Owen > -- > USMail: InterGuide Communications, 230 Lyn Anne Court, Ann Arbor, MI > 48103 > Phone:+1 734 997-0922 FAX: +1 734 661-0324 > mailto:[EMAIL PROTECTED] http://www.interguide.com/~osm/ > >
Re: [OT] Better Linux server platform: Redhat or SuSe?
On Wed, 3 Jul 2002 11:40:44 +0100, Jean-Michel Hiver wrote: > > perl: Any iussues with perl/modperl? Besides modperl I will be running a > > perl application with a few hundred thousend lines of code... > > Wow. For reference last time I looked at slashcode it was about 25.000 > lines I think. I wonder what kind of application would require more than > that amount of Perl code :-) I'm sure someone else will post a bigger number, but my application (IOP Electronic Journals) has 55000 lines of code (including the odd blank line and comment, of course). And we're always adding new stuff, so it only ever gets bigger. -- Peter Haworth [EMAIL PROTECTED] "We don't care how they do it in New York."
Re: Commercial use of mod_perl / modules]
On 29 Jun 2002 01:46:00 +0400, Ilya Martynov wrote: > >>>>> On Fri, 28 Jun 2002 16:38:25 -0500, Stephen Clouse > >>>>> <[EMAIL PROTECTED]> said: > > SC> On Fri, Jun 28, 2002 at 01:09:21PM +0100, Peter Haworth wrote: > >> The GPL doesn't restrict use, only distribution. > > SC> I believe you need to read it again. Its whole purpose of > SC> existence is to restrict use by non-free software. Link GPL code > SC> into your non-free app at your own risk. > > AFAIK it is OK as long as you do not distribute the result. Admittedly, it has been some time since I read it. However, I've just done so. Here are some quotes: > 0. Activities other than copying, distribution and modification are not > covered by this License; they are outside its scope. The act of running > the Program is not restricted, and the output from the Program is covered > only if its contents constitute a work based on the Program Running the program, and it's output are not restricted. Otherwise, everything compiled by gcc would be under GPL, which it isn't. > 2. You may modify your copy or copies of the Program or any portion of it, >thus forming a work based on the Program, and copy and distribute such >modifications or work under the terms of Section 1 above, provided that >you also meet all of these conditions: > b) You must cause any work that you distribute or publish, that in whole > or in part contains or is derived from the Program or any part thereof, > to be licensed as a whole at no charge to all third parties under the > terms of this License. This is the only condition in section 2 which mentions distribution. It doesn't say you have to distribute; only what applies if you do. These are from the GPL FAQ: > A system incorporating a GPL-covered program is an extended version of > that program. The GPL says that any extended version of the program must > be released under the GPL if it is released at all. But from my reading (which could be wrong, of course), it doesn't say that you have to release it. > What the GPL requires is that [someone with a copy of a GPL'ed program] > must have the freedom to distribute a copy to you if he wishes to. -- Peter Haworth [EMAIL PROTECTED] "Who is General Failure and why is he reading my disk?"
Re: Optional HTTP Authentication ?
Hi, Jean-Michel: the "official" way to retrieve the remote user name under
Basic Authentication is to call for $r->connect->user(), or $r->user() in
mod_perl 2.0, I think. With a ticket authentication, one gets the user name
in the same way only AFTER the access control phase, because it is simulated
from the ticket, see e.g. my Apache::CookieAccess source at
modperl.home.att.net. BTW, for me, Basic Authnetication is not that ugly, it
is surpringly stable (than most of other Apache ideas) since day one.
Peter Bi
- Original Message -
From: "Jean-Michel Hiver" <[EMAIL PROTECTED]>
To: "Peter Bi" <[EMAIL PROTECTED]>
Cc: "Jean-Michel Hiver" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Sunday, June 30, 2002 12:20 PM
Subject: Re: Optional HTTP Authentication ?
> On Sun 30-Jun-2002 at 10:47:26AM -0700, Peter Bi wrote:
> > Please check that the idea of this kind of authentication is to encrypt
the
> > ticket, instead of a plain session ID. If cookie is not available,
having
> > it on URI is a good idea. (Then one needs to have all links in a
relative
> > manner; see the Cookbook). Cookie itself does not make a secure session
ID
> > or a secure ticket. It is the encryption that does.
>
> I *CANNOT* use cookies nor URIs for any kind of session tracking.
> Otherwise I don't think I would have posted this message to the list in
> the first place :-)
>
> I agree that HTTP Basic authentication is totally and uterly ugly, but I
> am going to have to stick with it no matter what... My problem is:
>
> How do I tell apache to set the $ENV{REMOTE_USER} variable if the
> browser sent the credentials, or leave $ENV{REMOTE_USER} undef
> otherwise, without sending a 401 back.
>
> Cheers,
> --
> IT'S TIME FOR A DIFFERENT KIND OF WEB
>
> Jean-Michel Hiver - Software Director
> [EMAIL PROTECTED]
> +44 (0)114 255 8097
>
> VISIT HTTP://WWW.MKDOC.COM
>
Re: Optional HTTP Authentication ?
Please check that the idea of this kind of authentication is to encrypt the ticket, instead of a plain session ID. If cookie is not available, having it on URI is a good idea. (Then one needs to have all links in a relative manner; see the Cookbook). Cookie itself does not make a secure session ID or a secure ticket. It is the encryption that does. Peter Bi - Original Message - From: "Jean-Michel Hiver" <[EMAIL PROTECTED]> To: "Randal L. Schwartz" <[EMAIL PROTECTED]> Cc: "Jean-Michel Hiver" <[EMAIL PROTECTED]>; "Andrew Moore" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Sunday, June 30, 2002 10:07 AM Subject: Re: Optional HTTP Authentication ? > > What? The EU is going to make cookies *illegal*? I highly doubt > > this. > > Sorry, I am neither the lawyer nor the client, so I can't tell you... > I know it's really stupid, but I am going to have to deal without > cookies. > > > Jean-Michel> * For usability reasons encoding session IDs on URIs would be really > > Jean-Michel> bad... users needs to be able to 'hack' the URIs without f***ing their > > Jean-Michel> sessions! > > > > Why is a user "hacking" their URLs? > > I can answer that. http://www.useit.com/alertbox/990321.html > > > * a domain name that is easy to remember and easy to spell > * short URLs > * easy-to-type URLs > * URLs that visualize the site structure > * URLs that are "hackable" to allow users to move to higher levels of > the information architecture by hacking off the end of the URL > * persistent URLs that don't change > > > i.e. http://bigmegamarket.com/grocery/fruits/bananas/ is cool, > http://bigmegamarket.com/index.pl?id=231223412&sid=56765454151 is not. > > Again it doesn't always make implementation easy :-/ > > > Jean-Michel> Therefore I have to use HTTP authentication... > > > > Even though the user/password is transmitted *in the clear* on > > *every single hit*, because you can't just use a session identifier? > > This is so very wrong from a security perspective. > > I have to agree with you on that. Cookies are probably far better than > HTTP authentication. But I cannot use cookies. Period. I wish I could, > because this was what I did in the first place and it was working fine! > > Cheers, > -- > IT'S TIME FOR A DIFFERENT KIND OF WEB > > Jean-Michel Hiver - Software Director > [EMAIL PROTECTED] > +44 (0)114 255 8097 > > VISIT HTTP://WWW.MKDOC.COM
Re: .cgi with ModPerl
> "ebay" == ebay writes: ebay> I am setting up a server so that all my scripts have .cgi extentions. ebay> It would be nice if I could just add some directives in the httpd.conf ebay> that will have all my virtual hosts use modPerl for any files with ebay> either a .pl or a .cgi extention. The reason I prefer this method is ebay> that I have a couple scripts that I load in my httpdocs directory (the ebay> site home page is a script) So this is what I did: ebay> Commented out: AddHandler cgi-script .cgi ebay> Added the following: ebay> ebay> ebay> SetHandler perl-script ebay> PerlHandler Apache::PerlRun ebay> Options +ExecCGI ebay> allow from all ebay> PerlSendHeader On ebay> ebay> try FilesMatch instead and see if that works ebay> What I found is that when I only had this code only outside of the ebay> VirtualHost configurations, my test script indicated .pl was running in ebay> modPerl but .cgi wasn't. I only could get .cgi to run in mod_Perl by ebay> copying this code inside of each of the VirtualHost configurations. ebay> Obviously I'm not an Apache config expert but one thing that also struck ebay> me strange is that while this code clearly indicates how to handle .pl ebay> and .cgi file extentions, prior to adding this, I could not find ebay> anywhere in httpd.conf where it maps .cgi files in this same way. The ebay> only code I could find is AddHandler cgi-script .cgi but shouldn't there ebay> be some additional corresponding code like PerlHandler Appache::Mod_CGI, ebay> Options +ExecCGI, etc.?? Also, how does appache know which module to ebay> use for ScriptAlias directories? I left the ScriptAlias directives in ebay> for the cgi-bin director and didn't change them to just Alias directives ebay> and it works fine but I guess that means a filematch directive overrides ebay> a ScriptAlias directive? ebay> A bit confused. Anyway, is the above method for achieving what I want ebay> an acceptable and secure/safe way to handle it? ebay> Thanks -- XEmacs Advocate | I've seen things you people wouldnt believe. FreeBSD Devote | Attack ships on fire of the shores of orion ... Perl Hacker | All those moments will be lost in time, Apache God | like tears in the rain. Time to die.. roy batty - bladerunner
RE: Commercial use of mod_perl / modules
ask a lawyer. if you get taken to court "but some guy on some mailing list said it was ok" is not a great defence. all: can we please not turn this thread into a million and one personal interpretations of the situation. unless you are qualified to give a legal advice, you are just creating list fluff and wasting bandwidth. -pete -Original Message- From: Kirk Bowe [mailto:[EMAIL PROTECTED]] Sent: Friday, June 28, 2002 11:30 AM To: [EMAIL PROTECTED] Subject: Commercial use of mod_perl / modules I've been asked an interesting (though apologies if this is a heated or irelevant topic) question: what's the legality of using mod_perl (and indeed Apache), and the available modules, in a non-GPL commercial application for which there is a charge? I can't think of any modules off hand that are GPLd (most of the ones I've come across tend to say "this is freeware, you're free to use it as you wish so long as you preserve my copyright message", etc.). As far as I can see, therefore, it is fine to use Apache and most of the perl modules (if they're not GPLd), as supporting tools, in a commercial project without paying for, or infringing, any authors's rights. So long, I guess, as you make it clear that there is no charge for Apache or any of the associated perl modules that you use in that project, and produce a list of all the individual authors' copyright notices. Sorry -- don't want to turn this into a long thread about commercialism versus "freedom" -- just wondering if there is a clear stance on the issue. Cheers Kirk.
Re: when to mod_perl?
- Original Message -
From: "Randal L. Schwartz" <[EMAIL PROTECTED]>
To: "Peter Bi" <[EMAIL PROTECTED]>
Cc: "Perrin Harkins" <[EMAIL PROTECTED]>; "md" <[EMAIL PROTECTED]>;
"Stas Bekman" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Tuesday, June 25, 2002 10:18 AM
Subject: Re: when to mod_perl?
> >>>>> "Peter" == Peter Bi <[EMAIL PROTECTED]> writes:
>
> Peter> I have a question regarding to the cached files. Although the
> Peter> maximal period is set to be 24 hours in httpd.conf's proxy
> Peter> settings, many of the files, which were cached from the backend
> Peter> mod_perl dynamical program, are strangely modified every a few
> Peter> minutes. For all the files I checked so far, they do look to be
> Peter> modified because the hex strings on top of the files (such as
> Peter> 3D189FC2) are different after each modifications.
>
> If you're talking about www.stonehenge.com, I don't provide
> last-modified for any of the HTML pages: they're all dynamic. If the
> proxy server is caching them, it's going to still punch through to the
> back for each hit.
That is one of our sites.
>
> Similarly, if you are talking about your own site, and you *do*
> provide a mostly useless "last modified" time, then the front end is
> still going to go to the back end and say "I've got a version from
> time $x, is that current?" and if you're not handling
> "if-modified-since", then every hit will be cached, uselessly.
>
I used:
$r->update_mtime($id); # id is less than the current time and does not
change for a specific page
$r->set_last_modified;
if ($r->protocol =~ /(\d\.\d)/ && $1 >= 1.1){
$r->header_out('Cache-Control' => "max-age=" . 100*24*3600);
} else {
$r->header_out('Expires' => HTTP::Date::time2str($id + 100*24*3600));
}
It would not be surprising if none of the dynamic pages created was cached,
which then meant I had improper headers in mod_perl. In fact, they do serve
a number of views (maybe several tens) before modifying in the proxy
directory again. For example, I checked a file status:
$last access time: Tue Jun 25 11:44:12 2002
$last modify time: Tue Jun 25 11:40:52 2002
and for the same file later:
$last access time: Tue Jun 25 11:51:14 2002
$last modify time: Tue Jun 25 11:44:54 2002
so they were modified but not for every hits.
> I avoid that on stonehenge by not providing last-modified for any of
> my HTML pages. mod_proxy thus has no idea about caching, so it's all
> dynamic. My images automatically have last-modified, and thus the
> cache can check for updates with if-modified-since, using the cache
> when needed. If I was really smart, I'd use mod_expires to say "this
> image is good for $N hours", and then the front end wouldn't even
> touch the back end at all.
>
But if one makes a proper header, the proxy would not distinquish whether it
is static or dynamic. It should deliver or cache all the backend pages the
same way, providing the headers are right.
Here is another strange clue for me. The cached files have three extra
request headers "X-Forwarded-For:", "X-Host: ", "X-Server-Hostname: " (from
mod_proxy_forward). While the files are modified continuously, the
"X-Forwarded-For" header, which record a browser's IP, does NOT change
although the later hits come from completely different IPs.
> As I said, as long as my loadav is low enough for my current hits, I've
> got better things to work on. :)
>
> --
> Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777
0095
> <[EMAIL PROTECTED]> http://www.stonehenge.com/merlyn/>
> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
> See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl
training!
>
Peter Bi
Re: when to mod_perl?
> > Thanks to the caching, any of my images or other static content gets > pushed once a day to the front, and then doesn't tie up the back ever > again. . I have a question regarding to the cached files. Although the maximal period is set to be 24 hours in httpd.conf's proxy settings, many of the files, which were cached from the backend mod_perl dynamical program, are strangely modified every a few minutes. For all the files I checked so far, they do look to be modified because the hex strings on top of the files (such as 3D189FC2) are different after each modifications. Forgive me if this is off-topic: it is more likely a mod_proxy question. I searched, but could not find related information pages to read. Thanks. Peter Bi - Original Message - From: "Randal L. Schwartz" <[EMAIL PROTECTED]> To: "Perrin Harkins" <[EMAIL PROTECTED]> Cc: "md" <[EMAIL PROTECTED]>; "Stas Bekman" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Tuesday, June 25, 2002 8:38 AM Subject: Re: when to mod_perl? > >>>>> "Perrin" == Perrin Harkins <[EMAIL PROTECTED]> writes: > > Perrin> Static content is easy; just don't serve it from mod_perl. The proxy > Perrin> approach is good, and so is a separate image server (which you can > Perrin> host on the same machine). I've found thttpd to be an amazingly > Perrin> efficient server for images, but a slimmed-down apache does very well > Perrin> too. > > On the new www.stonehenge.com, I'm using a stripped down Apache (just > mod_proxy and mod_rewrite) for a reverse caching proxy, and it's about > 1.5M RSS per process. I divert requests for TT's /splash/images and > Apache's /icons, but otherwise, all content requests (including for > /merlyn/Pictures/ images) go to my heavyweight mod_perl backends, > which are running about 10M RSS. > > Thanks to the caching, any of my images or other static content gets > pushed once a day to the front, and then doesn't tie up the back ever > again. On a 500Mhz 256M box, I'm easily serving 50K requests a day > (about 10K of those are fully uncached dynamic pages touching about 20 > to 50 TT includes), with loadaverages staying below 0.5. If it ever > starts getting higher, I can cache the expensive menubar creation > (which is nearly completely static) using Perrin's device, but I've > not bothered yet. > > It's been amazingly carefree. I'm planning to move > www.geekcruises.com to be served on the same box, although they get > only about 1/10th the traffic. > > -- > Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 > <[EMAIL PROTECTED]> http://www.stonehenge.com/merlyn/> > Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. > See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training! >
Re: when to mod_perl?
wait a second ... don't forget using proxy: it saves you a lot of dynamical calls, especially if you have also a database. Peter Bi - Original Message - From: "md" <[EMAIL PROTECTED]> To: "Stas Bekman" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Monday, June 24, 2002 9:36 PM Subject: Re: when to mod_perl? > > --- Stas Bekman <[EMAIL PROTECTED]> wrote: > > In any case we are talking about registry scripts, > > aren't we? In that > > case it takes very little time to turn it on and off > > and test what is > > better. Unless you are talking about writing full > > fledged mod_perl API > > handlers, which is only when your should > > plan/analyze before you code. > > Actually at first I was planning to do full fledged > mod_perl handlers, so that's why I wanted to plan > before I coded. > > I was just a bit worried about the amount of static > content. In the past I've had a lot more hardware to > work with and I never had to worry about it much. > > I think you all have answered my question well enough > that I feel confortable sticking with straight > mod_perl. > > Thanks... > > __ > Do You Yahoo!? > Yahoo! - Official partner of 2002 FIFA World Cup > http://fifaworldcup.yahoo.com
Re: Preserving POST data on external redirect?
The link asks to change POST to GET. However, there is a limit on the length
of the URL so the POST data may be truncated and the redirect action may not
work properly.
Also, make sure to escapeURL() in the URL (which will also add extra chars
in the URL).
Peter Bi
- Original Message -
From: "Kirk Bowe" <[EMAIL PROTECTED]>
To: "Ken Y. Clark" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Monday, June 24, 2002 8:50 AM
Subject: Re: Preserving POST data on external redirect?
>
> Hi, yes that's one of the pages that I've been looking at, and the code is
> almost identical (I've tried M_GET / GET as well). Still nothing
> happening for me :-)
>
> Cheers
>
> Kirk.
>
>
>
> On Mon, 24 Jun 2002, Ken Y. Clark wrote:
>
> > On Mon, 24 Jun 2002, Kirk Bowe wrote:
> >
> > > Date: Mon, 24 Jun 2002 16:22:42 +0100 (BST)
> > > From: Kirk Bowe <[EMAIL PROTECTED]>
> > > To: [EMAIL PROTECTED]
> > > Subject: Preserving POST data on external redirect?
> > >
> > >
> > >
> > > Hi all, my content handler does some work with POSTed data, and at the
> > > end
> > > wants to redirect to a totally unrelated server, preserving the POST
data
> > > that the client originally sent, so that the unrelated server can do
its
> > > own further processing with its own mod_perl, cgi, or whatever.
> > >
> > > I can't get it to work, as I think I'm getting confused by some
> > > pre-Apache::Request hints that I've seen for this. This is the mess
I've
> > > got so far (condensed):
> > >
> > > sub handler
> > > {
> > > my $r = Apache::Request->new(shift);
> > >
> > > ... some calls to other subs here to do work ...
> > >
> > > $r->method("POST");
> > > $r->method_number(M_POST);
> > > $r->headers_in->unset("Content-length");
> > > $r->args($content);
> > > $r->header_out('Location' => "http://j.random.server.com/foo.cgi";);
> > > $r->status(REDIRECT);
> > > $r->send_http_header;
> > >
> > > return REDIRECT;
> > > }
> > >
> > > It redirects, but doesn't pass the POST data. I thought it may have
been
> > > due to the original post data being deleted because I use it, so I
tried
> > > using Request->instance instead of Request->new, but that made no
> > > difference either. Is it actually possible to do it if I'm using the
> > > Request object?
> > >
> > > Cheers
> >
> > I think this is what you want:
> >
> >
http://theoryx5.uwinnipeg.ca/cgi-bin/guide-filter?page=snippets/Redirect_a_P
OST_Request_Forward.html;query=GET%20POST;match=and;where=all;stem=no
> >
> > ky
> >
>
>
Re: [OT] what drives Amazon?
Hi, any comments on Java Servlet, .NET, mod_Perl and others such as ColdFusion ? I personally was asked for such question a few days ago. The other side needs a service like UPS.com. What do people on this mailing list think about ? Peter Bi - Original Message - From: "Perrin Harkins" <[EMAIL PROTECTED]> To: "F. Xavier Noria" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Saturday, June 15, 2002 4:36 PM Subject: Re: [OT] what drives Amazon? > > Does anybody know which is the technology behind Amazon? > > If you look at their job listings, you'll see it's a lot of C/C++ and > Perl, with a smattering of other things, running on Unix. That's pretty > typical of the really big sites. > > - Perrin > > >
Re: mod_perl/passing session information (MVC related, maybe...)
To Ward's first post: I think one may even doesn't need server cookie. Using a client-site cookie fits exactly the need. Peter - Original Message - From: "Rob Nagler" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, June 13, 2002 7:49 PM Subject: Re: mod_perl/passing session information (MVC related, maybe...) > Perrin Harkins writes: > > My preferred design for this is to set one cookie that lasts forever and > > serves as a browser ID. > > I like this. It's clean and simple. In this sense, a browser is not > really a session. The only thing I don't like is garbage collection. > > > unique browser ID (or session ID, if you prefer to give out a new one > > each time someone comes to the site) lets you track this for > > unregistered users. > > We call this a visitor id. In the PetShop we have a cart id, but > we're not too happy with the abstraction. > > > I don't see that as a big deal. You'd have to delete lots of other data > > associated with a user too. Actually deleting a user is something I've > > never seen happen anywhere. > > We do. Especially when we went from free to fee. :-( The big issue I > have with "session data" is that it is often a BLOB which you can't > query. > > > Well, eToys handled more than 2.5 million pages per hour, but caching > > can be important for much smaller sites in some situations. > > I'd like numbers on "smaller" and "some". :) > > > Here's a situation where a small site could need caching: > > We cache, too. An interesting query is the "club count" on > bivio.com's home page. The count of clubs is a fast query, but the > count of the members is not (about 4 seconds). We compute a ratio > when the server starts of the members to clubs. We then run the club > count query and use the ratio to compute the member count. We restart > the servers nightly, so the ratio is computed once a day. > > > Maybe I just have bad luck, but I always seem to end up at companies > > where they give me requirements like these. > > It's the real world. Denormalization is necessary, but only after you > test the normal case. One of the reasons I got involved in this > discussion is that I saw a lot of messages about solutions and very > few with numbers identifying the problem. > > Rob > > >
Re: Building high load mod_perl/Mason servers
General ideas are in Stas' introduction and other mod_perl books. Here are some practical numbers which may be useful for your reference. (assuming that all your servers have 1G RAM) 1) when daily unique IP are about 25K. Run mod_perl on the database machine with persistent Apache::DBI database connection. Turn one of the two frontend servers to be a light Apache server that a) serves all static contents and b) proxy to the mod_perl server for dynamical content. Leave the other frontend server to serve temporary PHP programs. With 1G in the frontend server, you are okay to run 500 MaxClients. 2) daily unique IPs are about 50k. Run both the frontend servers to be light Apaches and proxy to the mod_perl for dynamic contents. Memory may just be used up in the DB/mod_perl machine. If it is going to be a problem, try to remove Apache::DBI and use database cache to save memory but still keep a fast DB connection. Also, design the programs carefully to use caching ability in the light servers and/or to return proper headers (e.g. NOT_MODIFIED) as soon as possible. 3) daily unique IPs are about 100k. May need 3-4 frontend light Apaches, 1-2 mod_perl servers and 1 DB. Only with a daily unique IPs above 100k, one will defeintely needs two or more mod_perl servers. Synchronizing mod_perl codes should not be a problem --- for examply, simply mounted as NFS. Mod_perl calls the codes only once when starts. 4) Mason and other tools --- one can take the advantage for general development purposes. If the site has only a few specific services, it is better to write mod_perl from scratch than with a tool. These numebrs changed from sites to sites, I believe. The above numbers are based on our experience only. A popular web site usually contains many clients of slow network connections. So proxy is the key to serve them efficiently. Peter Bi - Original Message - From: "Eric Frazier" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, June 06, 2002 7:43 PM Subject: Building high load mod_perl/Mason servers > Hi, > > I just got the chance to be in charge of a very busy website, and its future > growth. Currently it is running with PHP on two round robin servers with a > separate mysql db server. We are going to be moving to mod_perl, but I am > worried about how to keep from getting into the same kind of trap with > mod_perl as with PHP. The PHP guys don't know OOP, so we have to code > halfway, modules exporter but not OOP modules. It has to be something OOP > like without getting too complex at first. The PHP trap is just the horrible > require once stuff all over the place and global vars etc. I know lots of > people blame this kind of coding on perl geeks, but the PHP stuff I have > been seeing is pretty bad with it because the constant thought is "must fix > current problem wait till later to be pretty" but later never comes. Also > things like using ten instr functions instead of one reg exp. > > So I am thinking whatever I do it should fit within an existing framework, > something like Mason. But I am confused about what real advatage Mason > provides, and how things like source code control would work if we are > running lots of servers. Do people use rsync to keep up to date? Say one > machine is always the upload point and the rest get synced from that one? I > am having a hard time asking really good questions I think because there are > so many things I am trying to think out. > > > Thanks for any ideas, > > > Eric > > http://www.kwinternet.com/eric > (250) 655 - 9513 (PST Time Zone) > > "Inquiry is fatal to certainty." -- Will Durant > > > > >
Re: Perl written in mod_perl
On 21 May 2002 at 22:23, Gregory Matthews wrote: > Here's an odd question for you. Why is it when I go to places like > cgi-resources.com and other cgi repositories, mod_perl applications > are far and few between...commercially that is? > > All I see are common cgi scripts written in plain perl. > > Does it have anything to do with the configurability tasks involved on > the customers box, i.e., once the sale is made? > > If this is the wrong place for a question like this, I apologize. > Just curious. I think it's a good question. Unlike I reckon most people on this list, I live in a virtual world. I started my first programming job at an ad agency and even the site we did for FedEx went on a virtual server. I think the vast majority of people out there are also running virtual servers. Only recently did the company we host at offer mod_perl as an option. But then to offer an application for the public at large (not just to mod_perl developers) to download and install ... well, that's another beast. Always best to look at those with some expertise. Extropia for example. I downloaded their ProjectTracker and it was a cgi installation (and made extremely easy to install). I didn't look but I bet I could turn it into a handler. I took their experience and turned my image gallery application into a cgi application. Anyone who knows can turn the cgi handlers into mod_perl handlers otherwise it will work in standard cgi environment or under Apache::Registry. Even so, when helping people (and usually people for whom an ftp gui is "tech") install cgi applications on virtual servers is rarely simple. Even today I cannot run most of the large scale mod_perl applications as I'm still using virtual servers and most of the mod_perl apps require a greater degree of control than I have. PHP on the other hand, it's everywhere. I have a link to a PHP image gallery on my site that is quite nice. I offer it as an alternative to my application . It can be installed from the web browser. I have installed Perl cgi applications where that was been done as well. I cannot imagine doing that for mod_perl applications though. In short, mod_perl applications using handlers has a very dedicated and passionate but limited audience imho. Peter -- http://www.readbrazil.com/ Answering Your Questions About Brazil
Re: Getting mod_perl to work under Win2k
Michael Lawrie wrote: > Hello, > I've spent several days working on this problem, reading various FAQ and > whatnot and finally decided to try this email list, hoping that I might find > an answer here. > > I'm running Win2KPro and Apache 1.3.23 > I downloaded mod_perl2.ppd, and installed the *.so file in the default modules > directory for my web server. > > I edited the httpd.conf file to include the following line: > LoadModule perl_module modules/mod_perl.so > > When I attempt to start httpd I get this message: > Syntax Error on line 193 of c:/apache/apache/conf/httpd.conf > Can not load c:/apache/apache/modules/mod_perl.so into server: (126) The > specified module could not be found. > > Is there something I've missed? Looks like your PATH env variable needs to be modified to include your Perl executable. Make sure you are getting the correct the with a perl -V from the command prompt. -pete > > > Thanks! > Michael
Re: [modperl2] Note on the win32 docs
Thanks for the info. Latest from cvs works fine.
Any idea how close _02 might be to release?
-pete
Doug MacEachern wrote:
> On Mon, 20 May 2002, Peter Rothermel wrote:
>
> > I've run into a problem with mod_perl configuration instructions
> > with for Registry scripts. I've built mod_perl and copied the
> > blib directly under my Apache2 (server root) directory.
>
> sounds like a bug that has been fixed in cvs. try the cvs version or wait
> for _02 or try the patch below.
>
> Index: ModPerl-Registry/lib/ModPerl/RegistryCooker.pm
> ===
> RCS file: /home/cvs/modperl-2.0/ModPerl-Registry/lib/ModPerl/RegistryCooker.pm,v
> retrieving revision 1.5
> retrieving revision 1.6
> diff -u -r1.5 -r1.6
> --- ModPerl-Registry/lib/ModPerl/RegistryCooker.pm 13 Nov 2001 04:34:31 -
> 1.5
> +++ ModPerl-Registry/lib/ModPerl/RegistryCooker.pm 16 Apr 2002 17:14:16 -
> 1.6
> @@ -42,10 +42,11 @@
> # httpd.conf with:
> # PerlSetVar ModPerl::RegistryCooker::DEBUG 4
> use Apache::ServerUtil ();
> -use constant DEBUG =>
> -defined Apache->server->dir_config('ModPerl::RegistryCooker::DEBUG')
> -? Apache->server->dir_config('ModPerl::RegistryCooker::DEBUG')
> -: D_NONE;
> +use constant DEBUG => 0;
> +#XXX: below currently crashes the server on win32
> +#defined Apache->server->dir_config('ModPerl::RegistryCooker::DEBUG')
> +#? Apache->server->dir_config('ModPerl::RegistryCooker::DEBUG')
> +#: D_NONE;
>
> #
> # object's array index's access constants
Re: [modperl2] Note on the win32 docs
I've run into a problem with mod_perl configuration instructions with for Registry scripts. I've built mod_perl and copied the blib directly under my Apache2 (server root) directory. Here's the errors I get run I start apache: C:\WGTI\Apache2\bin>apache Using C:\WGTI\Apache2/blib [Mon May 20 13:42:35 2002] [error] Attempt to free unreferenced scalar at C:\WGT I\Apache2/blib/lib/Apache2/ModPerl/RegistryCooker.pm line 45. BEGIN failed--compilation aborted at C:\WGTI\Apache2/blib/lib/Apache2/ModPerl/Re gistryCooker.pm line 48. Compilation failed in require at C:\WGTI\Apache2/blib/lib/Apache2/ModPerl/Regist ry.pm line 11. BEGIN failed--compilation aborted at C:\WGTI\Apache2/blib/lib/Apache2/ModPerl/Re gistry.pm line 11. Compilation failed in require at C:/WGTI/Apache2/conf/extra.pl line 15. BEGIN failed--compilation aborted at C:/WGTI/Apache2/conf/extra.pl line 15. Compilation failed in require at (eval 1) line 1. [Mon May 20 13:42:35 2002] [error] Can't load Perl file: C:/WGTI/Apache2/conf/ex tra.pl for server spider.inside.sealabs.com:80, exiting... Here's snipet of my httpd.conf file: LoadModule perl_module modules/mod_perl.so PerlSwitches -Mblib=C:\WGTI\Apache2 PerlModule Apache2 PerlModule Apache::compat PerlRequire "C:/WGTI/Apache2/conf/extra.pl" Here's my extra.pl use Apache2 (); use ModPerl::Util (); use Apache::RequestRec (); use Apache::RequestIO (); use Apache::RequestUtil (); use Apache::Server (); use Apache::ServerUtil (); use Apache::Connection (); use Apache::Log (); use Apache::Const -compile => ':common'; use APR::Const -compile => ':common'; use APR::Table (); use Apache::compat (); use ModPerl::Registry (); use CGI (); 1;
Re: Setting require in Authentication handler?
A remark: in many cases, the authentication against the password file can be replaced by verifying valid FTP/Telnet login to "localhost", not only because the password (shadow) file is usually not avialble for Apache account but also secure. In the ticketing system, the FTP/Telnet authentication runs only at the first time of login and the follow-up access can goes without re-FTP and so is pretty fast. Check this : http://modperl.home.att.net Peter Bi - Original Message - From: "Geoffrey Young" <[EMAIL PROTECTED]> To: "Todd Chapman" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Monday, May 20, 2002 6:50 AM Subject: Re: Setting require in Authentication handler? > > > Todd Chapman wrote: > > > That makes sense. I can't use mod_auth because I can't set Require. > > > well, if you're saying that you don't have the ability to set the Require directive at all > (as in you don't have access to edit httpd.conf), then you can't run any authentication > handler - mod_auth, mod_perl, or otherwise. Apache core requires the Require directive to > be set to something before it will even try to run the authen/authz phases of the request. > > so, you may be out of luck and need to resort to the CGI tricks of yore where everything > is clumped in the content-generation phase (and of which I'm not that familiar). > > > I'm > > using Basic authentication and text based password files. Unfortunately, I > > can't find an Apache::Auth* module that handles basic authentication > > against text files. Did I miss it somewhere? > > > I'm not sure, but it may not exist for the reason I stated eariler about mod_perl not > duplicating default Apache behavior. IIRC, there is one that authenticates against > /etc/passwd, so maybe you can use that as an example of flat file based processing. > > in general, though, the steps are pretty much the same no matter which authentication > method you choose. see > >http://www.modperlcookbook.org/code/ch13/Cookbook/Authenticate.pm > > for an example - all you need to do is replace the authenticate_user() subroutine with > calls that validate the user based on your own criteria. > > HTH > > --Geoff > > > > >
Re: Scripts and passwd
> I dont even > know if you can do it any other way with out touching the passwd/shadow > files? Do you run this for internet or your intranet accounts ? If for internet, try something different (e.g. Courier/IMAP.) If for intranet, and if you have to stay with Pop3, there is no way but to touch the password file. If you don't mind a web-based mail, a possible solution may like this: 1) set up a normal web-based membership service; 2) write a mail filter; 3) catch every email and check if the recipient is in your database, (yes) ? move the mail to the DB : normal mailbox. Well, I think someone's in this maillist may have already such a system and can share their experience. On the other hand, while this has a lot to do with Perl, it has little with mod_Perl. Peter - Original Message - From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, May 19, 2002 1:56 AM Subject: Re: Scripts and passwd > > Hello > > Thanks for the reply. Yes this server is running mod perl :) > > As for risky. Well the whole point of the script system is to add a pop mail > box for a user. But in order to do this i have to do the following: > > add user to the passwd/shadow file > add user to the virtusertable and genericstable > recompile the sendmail config files > > Then and only then is the new mailbox ready for use. This is the only way I > can think of to accomplish this via an automated web proccess. I dont even > know if you can do it any other way with out touching the passwd/shadow > files? > > Thanks! John. > > > You're doing something pretty risky there. the passwd/shadow files are > only > > writable by root. So I suppose that when running them from the command > line > > you run them as root. Apache doesn't run as root (its children which serve > > the requests atleast), so mod_perl (I suppose you *are* using mod_perl? If > > not, this is more appropriate for another newsgroup) won't either. > > > > If you can run your script as CGI, you could use suEXEC. But really, > really > > consider the security implications of what you're doing there before > > allowing users to trash your machine very fast... > > > > > > -- > > Per Einar Ellefsen > > [EMAIL PROTECTED] > > > > > >
Re: compatibility problem
You'll find a few other issues with AuthCookie and mod_perl-1.9.9_01
beyond the REDIRECT constant. Here's a quick summary:
1) move all the $r->connection->user() calls to $r->user() calls
2) change all the err_header_out() calls to err_headers_out() calls.
< $r->err_headers_out->{'Pragma'} = "no-cache";
---
> $r->err_header_out("Pragma" => "no-cache");
This is the bulk of the changes that I did to get things going. I'm
going to send my in to the maintainer of the Module as soon as I
get some help with method handles. This module makes use of
the technique of derived method handlers. I have been able to get
a regular, much less a derived, method handler working in mod_perl1.99.
As a temporary hack I hacked the module code to be a non-method handler.
good luck,
-pete
Stas Bekman wrote:
> Jie Gao wrote:
> > Hi all,
> >
> > I've been trying to get httpd-2.0.35 + mod_perl-1.99_01 work with backward
> > compatibility.
> >
> > MY startupl.pl:
> >
> > #! /usr/bin/perl
> > use lib '/usr/lib/perl5/site_perl/5.6.1/i386-linux/Apache2';
> > use strict;
> > use Apache::compat ();
> > use Apache2 ();
> > use My::AuthCookieHandler;
> > 1;
> >
> > and this script won't run to finish with the error:
> >
> > unknown group `response' at /usr/lib/perl5/site_perl/5.6.1/My/AuthCookieHandler.pm
>line 6.
> > BEGIN failed--compilation aborted at
>/usr/lib/perl5/site_perl/5.6.1/My/AuthCookieHandler.pm line 6.
> > Compilation failed in require at ./startup.pl line 6.
> > BEGIN failed--compilation aborted at ./startup.pl line 6.
> >
> > And this is the line in question:
> >
> > use Apache::Constants qw(:common :response M_GET M_POST AUTH_REQUIRED REDIRECT);
> >
> > If I take out response, it croaks at "REDIRECT".
> >
> > Any ideas why?
>
> Yes, it's not fully compatible :( in 2.0 we take all the Constants from
> APR and Apache, and they have changed. I guess we can manually do the
> adjustments in compat.pm. Currently there is no group :response in
> Apache::Const, these mainly reside in the new group :http and all the
> codes start with HTTP_
>
> For now try to replace
> REDIRECT with HTTP_TEMPORARY_REDIRECT
> and whatever constants you need from :response by looking them up in
> xs/ModPerl/Const/modperl_constants.c (which is autogenerated when you
> build mod_perl).
>
> We will discuss this issue at the dev list and the compat docs will be
> updated appropriately.
>
> __
> Stas BekmanJAm_pH --> Just Another mod_perl Hacker
> http://stason.org/ mod_perl Guide ---> http://perl.apache.org
> mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
> http://modperlbook.org http://apache.org http://ticketmaster.com
[JOB SEEK] Toronto - Re: [JOB] Mod_Perl/Sys Admin/HTML Tech Support - Los Angeles, CA
Hi, I shall fit 99% to Frank's job :-), but I have to move to Toronto soon. Looking for a mod_Perl or Perl related job in GTA (Toronto and Southern Ontario, Canada). Off-site contractor job is okay too. ASAP. Please check my resume at http://modperl.home.att.net . Thanks. Peter Bi p.s. I resist shifting to J2EE! - Original Message - From: "Frank Scannello" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, May 13, 2002 4:56 PM Subject: [JOB] Mod_Perl/Sys Admin/HTML Tech Support - Los Angeles, CA > The Partner Technical Team Support Engineer is dedicated to helping Partners > maintain and administrate the Citysearch software. Because Partner needs, > technologies, business requirements and languages vary widely, the candidate > must be able to communicate effectively. > > Location: must be able to commute to 3701 Wilshire blvd in Los Angeles, CA. > Relocation assistance not provided. > > Qualifications > * Experience working in a "webmaster-like" role. A true web technologies > generalist (part system administration (linux/unix), part front-end > development (strong HTML), part back-end development (perl cgi, mod_perl > ideal). > * Significant Experience with perl scripting > * Required - extensive knowledge of HTML. > * Unix environment (basic administration) - 2 years > > I am assisting my client in finding and selecting qualified candidates for > this position. The client is Ticketmaster City Search. Please respond with > resume to: > > Frank Scannello > Contract Recruiter > [EMAIL PROTECTED] > 904-543-0808 > > >
Re: cannot build mod_perl-1.99_01 with httpd-2.0.36
I'm getting the same error on Win32 builds. I just assumed that mod_perl-1.99_01 and httpd-2.0.36 were not compatible. I've been compiling with httpd-2.0.35 and to avoid the error. The file apr_lock.h is missing in the httpd-2.0.36 include directory but present in the httpd-2.0.35 source tree. -pete Tom Kralidis wrote: > > > > > > % perl Makefile.PL MP_AP_PREFIX=/usr/local/src/apache/httpd-2.0.36 > > > >MP_AP_PREFIX needs to be a directory where apache is installed, not the > >source tree. when apache is installed it puts all headers into the > >installed include/ directory. > > Thanks for the info. That didn't seem to work either > > cd "src/modules/perl" && make > make[1]: Entering directory > `/usr/local/src/apache/httpd-2.0.36/mod_perl-1.99_01/src/modules/p > erl' > gcc -I/usr/local/src/apache/httpd-2.0.36/mod_perl-1.99_01/src/modules/perl > -I/usr/local/src/ap > ache/httpd-2.0.36/mod_perl-1.99_01/xs -I/www/include -fno-strict-aliasing > -I/usr/local/include > -I/usr/lib/perl5/5.6.1/i386-linux/CORE -DMOD_PERL -O2 -march=i386 > -mcpu=i686 -fPIC \ > -c mod_perl.c && mv mod_perl.o mod_perl.lo > In file included from mod_perl.h:4, > from mod_perl.c:1: > modperl_apache_includes.h:46:22: apr_lock.h: No such file or directory > make[1]: *** [mod_perl.lo] Error 1 > make[1]: Leaving directory > `/usr/local/src/apache/httpd-2.0.36/mod_perl-1.99_01/src/modules/pe > rl' > make: *** [modperl_lib] Error 2 > > ...I have no apr_lock.h in /www/includes. Do I need libapreq? If so, that > install does not work either: > > ... > apache_cookie.c:117: `c' undeclared (first use in this function) > apache_cookie.c:118: invalid lvalue in assignment > apache_cookie.c:120: request for member `r' in something not a structure or > union > apache_cookie.c: At top level: > apache_cookie.c:144: parse error before `*' > apache_cookie.c: In function `ApacheCookie_parse': > apache_cookie.c:147: `retval' undeclared (first use in this function) > apache_cookie.c:148: parse error before `)' > apache_cookie.c:148: invalid lvalue in assignment > apache_cookie.c:151: warning: assignment makes pointer from integer without > a cast > apache_cookie.c:156: `c' undeclared (first use in this function) > apache_cookie.c:182: parse error before `)' > apache_cookie.c: At top level: > apache_cookie.c:196: parse error before `*' > apache_cookie.c: In function `escape_url': > apache_cookie.c:198: `p' undeclared (first use in this function) > apache_cookie.c:198: `val' undeclared (first use in this function) > apache_cookie.c: At top level: > apache_cookie.c:230: parse error before `*' > apache_cookie.c: In function `ApacheCookie_as_string': > apache_cookie.c:232: `array_header' undeclared (first use in this function) > apache_cookie.c:232: `values' undeclared (first use in this function) > apache_cookie.c:233: `pool' undeclared (first use in this function) > apache_cookie.c:233: `p' undeclared (first use in this function) > apache_cookie.c:233: `c' undeclared (first use in this function) > apache_cookie.c:234: parse error before `char' > apache_cookie.c:248: `cookie' undeclared (first use in this function) > apache_cookie.c:249: `i' undeclared (first use in this function) > apache_cookie.c:256: `retval' undeclared (first use in this function) > apache_cookie.c: At top level: > apache_cookie.c:265: parse error before `*' > apache_cookie.c: In function `ApacheCookie_bake': > apache_cookie.c:267: `c' undeclared (first use in this function) > make[1]: *** [apache_cookie.lo] Error 1 > make[1]: Leaving directory > `/usr/local/src/apache/httpd-2.0.36/libapreq-1.0/c' > make: *** [all-recursive] Error 1 > > Any suggestions? > > Thanks > > ..Tom > > _ > MSN Photos is the easiest way to share and print your photos: > http://photos.msn.com/support/worldwide.aspx
Re: [modperl2] Note on the win32 docs
Randy Kobes wrote: > On Mon, 13 May 2002, Peter Rothermel wrote: > > The blib/ directory under C:/Apache2 doesn't actually > have to be moved anywhere - one includes it with the directive > PerlSwitches -Mblib=C:\Apache2 > specified in the supplied httpd.conf So, for this > distribution, one doesn't need to do anything with the > Perl stuff ... Or am I misunderstanding something? When you built the mod_perl distribution did you use perl Makefile.PL MP_AP_PREFIX=C\Apache2 MP_INST_APACHE2=1 LIB=C:\Apache2\blib\lib thanks pete > > > best regards, > randy
Re: [modperl2] Note on the win32 docs
Excellent document. A slight enhancement request. Could you give some details on how to separate the modperl installation from the Perl installation? I believe the latest binary release has the mod_perl installed in a separate blib under the C:\Apache2 directory. thanks -pete > __ > Stas BekmanJAm_pH --> Just Another mod_perl Hacker > http://stason.org/ mod_perl Guide ---> http://perl.apache.org > mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com > http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Problems with Apache-AuthCookie mod_perl 1.99
Michael, I've got most of the changes done. No major changes were required but I'm still stuck on mod_perl 2's new method handlers. To get past this hurdle I've moved away from method handlers and put everything into a single package. As soon as somebody gives me a hand with method handlers ala 2.0 I'll forward the code to you. -pete Michael J Schout wrote: > On Thu, 2 May 2002, Per Einar Ellefsen wrote: > > > At 21:25 02.05.2002, Peter Rothermel wrote: > > >greetings, > > > > > >Has anybody had any luck getting Apache-AuthCookie going > > >on an Apache 2.0 / mod_perl 1.99 setup? The first thing that > > >I hit was $r->connection->user is deprecated. I've changed these > > >to $r->user. The next hurdle is that the status code REDIRECT > > >does not seen to be Apache::Constants. > > > > mod_perl 2 doesn't have Apache::Constants. You should use: > > > > use Apache::Const -compile => qw(... REDIRECT ..); > > > > Good luck on porting it to mod_perl 2! once you get it to work, it would be > > great if you could contribute it to the community! > > If you do get it working, feel free to forward patches to me as I am the > AuthCookie maintainer. > > An apache 2.0 port is on my TODO list. > > Mike
Re: err_header_out() not found in mod_perl 1.99
Nevermind, I found that err_headers_out() provides the needed functionality. Peter Rothermel wrote: > greetings, > > I'm using Apache2/mod_perl 1.99 on WinNT. > > Here's the error: > > [error] [client 127.0.0.1] Can't locate object method "err_header_out" via package >"Apache::RequestRec" at C:\Apach... > > thanks in advance > -pete
err_header_out() not found in mod_perl 1.99
greetings, I'm using Apache2/mod_perl 1.99 on WinNT. Here's the error: [error] [client 127.0.0.1] Can't locate object method "err_header_out" via package "Apache::RequestRec" at C:\Apach... thanks in advance -pete
Re: Cheap and unique
Does the first email mean to use the incrementing numbers as seeds and then generate "cool" random numbers from the partly ordered seeds, which will make them more difficult to guess ? Peter Bi - Original Message - From: "James G Smith" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Monday, May 06, 2002 11:45 AM Subject: Re: Cheap and unique > [EMAIL PROTECTED] wrote: > >I've been following this conversation and I'd like to clarify whether my > >idea (since I and others want to do this as well) would be use an > >incrementing counter for uniqueness. Then also store a bit of secret > >randomness, concatenate both values together and create a digest hash. > >That hash would be sent along with the sequence as well. This would allow > >uniqueness and prevent guessing since the digest would have to match as > >well. Depending on my paranoia I could either get fresh random bits each > >time (and have a good hardware source for this then) or keep it around for > >a bit and throw it away after a period. > > I think I understand you correctly, but I'm not sure. > > You mention the sequence being incremented for uniqueness and the > digest. I think you propose to send the sequence along with the > digest (the digest containing that bit of randomness along with the > sequence), but you also mention keeping the random bits around for > only a short time, which would indicate they aren't being used to > verify the sequence, but produce the sequence via the hash. > > A digest is not unique, especially with the random bit of data thrown > in. For example, MD5 has 128 bits, but can hash any length string. > There are more than 2^128 strings that MD5 can take to 128 bits. > Therefore, MD5 does not produce a unique value, though it is a > reproducable value (the same input string will always produce the > same output string). You can replace MD5 with MHX (my hash X) and > the number of bits with some other length and the results are still > the same -- in other words, no hash will give unique results. > > The secret string concatenated with the unique number and then hashed > can be used to guarantee that the number has not been tampered with, > but the secret string would need to be constant to be able to catch > tampering. Otherwise, how can you tell if the hash is correct? > -- > James Smith <[EMAIL PROTECTED]>, 979-862-3725 > Texas A&M CIS Operating Systems Group, Unix >
Re: problems setting up Apache::AuthCookieDBI (solved but no fully understood)
Try my Apache::AccessCookie too. It provides the same ticketing interface for many different authenticating methods such as LDAP, IMAP, ftp, SMB, and (of course) DBI, plus a number of useful features. One can simply implement her own mechanism too. It can be downloaded at http://mod_perl.home.att.net. BTW, I tried to register the module in CPAN, but was kind of lost in the middle. Peter Bi - Original Message - From: "Jim Helm" <[EMAIL PROTECTED]> To: "'Fran Fabrizio'" <[EMAIL PROTECTED]>; "'F.Xavier Noria'" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Friday, May 03, 2002 10:08 PM Subject: RE: problems setting up Apache::AuthCookieDBI (solved but no fully understood) > p.s. FWIW, I ended up using Apache::AuthTicket instead - has a feature I > wanted (timeout, not just expiry), which CookieDBI didn't have), and it > worked as documented with zero hassle... > > Jim > > > > -Original Message- > > > From: Fran Fabrizio [mailto:[EMAIL PROTECTED]] > > > Sent: Friday, May 03, 2002 6:38 AM > > > To: F.Xavier Noria > > > Cc: [EMAIL PROTECTED] > > > Subject: Re: problems setting up Apache::AuthCookieDBI > > > (solved but no fully understood) > > > > > > > > > > > > > > > > > >Does the server load the module that way? > > > > > > > > > > > It's beyond my expertise at this point but my experience > > > would indicate > > > that it does not work this way since I have PerlModule before the > > > PerlSetVar and it works fine. > > > > > > -Fran > > > > > > > > > > > > >
Re: Help with Method Handlers in mod_perl 1.99
I tried the mehod attribute and now I get this error:
Error message:
Can't locate object method "" via package "Apache::AuthDerivedHandler".
Geoffrey Young wrote:
> Peter Rothermel wrote:
>
> > Can somebody help me out with Method Handlers in
> > Apache2 - mod_perl 1.99? I'm new to windows and its
> > threading issues.
>
> [snip]
>
>
> > sub authenticate ($$) {
> > my ($self, $r) = @_;
> > return OK;
> > }
>
> I haven't played much with mod_perl 2.0 yet, but I know that this format is
>deprecated now.
>
> instead, try
>
> sub authenticate : method {
>...
> }
>
> and look for method handlers in design.pod and compat.pod
>
> HTH
>
> --Geoff
Help with Method Handlers in mod_perl 1.99
Can somebody help me out with Method Handlers in
Apache2 - mod_perl 1.99? I'm new to windows and its
threading issues.
Here's a simple authentication handler that shows where
I'm getting stuck. I need to initialize a AuthDerivedHandler
object but I'm not sure exactly how to do this.
package Apache::AuthBaseHandler;
use strict;
use Apache::Constants qw(:common);
use vars qw($VERSION);
$VERSION = '3.00';
sub authenticate ($$) {
my ($self, $r) = @_;
return OK;
}
sub new {
my $this = shift;
my $class = ref($this) || $this;
my $self = {};
bless $self, $class;
return $self;
}
1;
__END__
package Apache::AuthDerivedHandler;
use strict;
use Apache;
use Apache::Constants qw(:common);
use Apache::AuthBaseHandler;
use vars qw($VERSION @ISA);
$VERSION = "1.0";
@ISA = qw(Apache::AuthBaseHandler);
sub NonMethodAuthHandler($) {
my $r = shift;
my $authhandler = Apache::AuthDerivedHandler->new();
return $authhandler->authenticate($r);
}
1;
In my httpd.conf I have the following directives:
PerlOptions +GlobalRequest
SetHandler perl-script
AuthType Apache::AuthCookieHandler
PerlAuthenHandler Apache::AuthDerivedHandler->authenticate
PerlHandler Apache::hello
require valid-user
PerlOptions +GlobalRequest
SetHandler perl-script
AuthType Apache::AuthCookieHandler
PerlAuthenHandler Apache::AuthDerivedHandler->authenticate
PerlHandler Apache::hello
require valid-user
In my startup.pl in have:
$ENV{MOD_PERL} or die "not running under mod_perl!";
use Apache2 ();
use Apache::compat ();
use Carp ();
use CGI ();
CGI->compile(':all');
CGI->compile(':standard');
use CGI::Carp;
use Apache::AuthDerivedHandler;
1;
Problems with Apache-AuthCookie mod_perl 1.99
greetings, Has anybody had any luck getting Apache-AuthCookie going on an Apache 2.0 / mod_perl 1.99 setup? The first thing that I hit was $r->connection->user is deprecated. I've changed these to $r->user. The next hurdle is that the status code REDIRECT does not seen to be Apache::Constants. -pete
Is ActivePerl required with a mod_perl-Apache installation
Is there anyway to build mod_perl and Apache so that my target installation does not require ActivePerl on WinNT platforms. I'm currently doing my development on a WinNT that has ActivePerl installed and in my PATH. This is where I'm developing perl modules. When I move my installation over to a test WinNT machine without ActivePerl I get an error when Apache hits the LoadModule line for mod_perl.so. -pete
Re: full-featured online database apps
(agreed. let's stop talking on specific templates.) As to the reusability, form actions can actually be put in an abstract class, so a particular application can subclass it by implement of action methods with an optional xml control. But I have the same feeling as in Ken Clark's original post, one could not go too far beyond that, or not worth of doing that. Using an existing tool may solve one problem but it usually takes as much time to add or modify something later. On the other hand, the typical size of web projects nowadays is still well within our ability of write-from-scratch. Peter - Original Message - From: "Perrin Harkins" <[EMAIL PROTECTED]> To: "Peter Bi" <[EMAIL PROTECTED]> Cc: "Wim Kerkhoff" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; "Ken Y. Clark" <[EMAIL PROTECTED]> Sent: Wednesday, April 24, 2002 2:08 PM Subject: Re: full-featured online database apps > Peter Bi wrote: > > Well, I changed it back to "HTML::Template". > > No template flame wars, please. HTML::Template is not unique (it has > much in common with Template Toolkit and dozens of other less famous > modules from CPAN), and Embperl::Object is really pretty cool. Your > original point about separating presentation out into templates helping > with code reusability is a good one, so let's just leave it at that. > > - Perrin > >
Re: full-featured online database apps
Well, I changed it back to "HTML::Template" . It takes relatively less time to work it out with graphic designers. Peter - Original Message - From: "Wim Kerkhoff" <[EMAIL PROTECTED]> To: "Peter Bi" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; "Ken Y. Clark" <[EMAIL PROTECTED]> Sent: Wednesday, April 24, 2002 1:50 PM Subject: Re: full-featured online database apps > "Since the excellent HTML::Template, the code becomes more re-usable..." > > Sorry, had to be said. My point is that there are many templating systems to > choose from. With a bit of fore thought, the Show, List, Delete, Add, etc > buttons can be moved into different objects/methods/templates, so that it's > easier to pick and choose your interface components. > > Wim > > On 24-Apr-2002 Peter Bi wrote: > > Since the excellent HTML::Template, the codes becomes more re-usable... > > > > Peter > > > > - Original Message - > > From: "Ken Y. Clark" <[EMAIL PROTECTED]> > > To: "Adi Fairbank" <[EMAIL PROTECTED]> > > Cc: <[EMAIL PROTECTED]> > > Sent: Wednesday, April 24, 2002 1:23 PM > > Subject: Re: full-featured online database apps > > > > > > > >> > >> I've written so many on-line database apps in mod_perl/MySQL/Oracle > >> that I think I'll go crazy sometimes. They all have so much in > >> common, esp. the typical administrative interface where you have to > >> "show all," "show one," "edit," "create," "[confirm] delete," etc. > >> Everytime I find myself following the same basic formula, but they're > >> all so significantly different that I can't really see reusing much > >> code. I guess you could abstract things to such a degree that > >> lots of directives could be passed to extremely generic methods, but > >> that actually has always seemed more trouble to me than it's worth. >
Re: full-featured online database apps
Since the excellent HTML::Template, the codes becomes more re-usable... Peter - Original Message - From: "Ken Y. Clark" <[EMAIL PROTECTED]> To: "Adi Fairbank" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Wednesday, April 24, 2002 1:23 PM Subject: Re: full-featured online database apps > > I've written so many on-line database apps in mod_perl/MySQL/Oracle > that I think I'll go crazy sometimes. They all have so much in > common, esp. the typical administrative interface where you have to > "show all," "show one," "edit," "create," "[confirm] delete," etc. > Everytime I find myself following the same basic formula, but they're > all so significantly different that I can't really see reusing much > code. I guess you could abstract things to such a degree that > lots of directives could be passed to extremely generic methods, but > that actually has always seemed more trouble to me than it's worth. >
Re: Throttling, once again
How about adding a MD5 watermark for the cookie ? Well, it is becoming complicated Peter Bi - Original Message - From: "kyle dawkins" <[EMAIL PROTECTED]> To: "Peter Bi" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Friday, April 19, 2002 8:29 AM Subject: Re: Throttling, once again > Peter > > Storing the last access time, etc in a cookie won't work for a perl script > that's abusing your site, or pretty much any spider, or even for anyone > browsing without cookies, for that matter. > > The hit on the DB is so short and sweet and happens after the response has > been sent to the user so they don't notice any delay and the apache child > takes all of five hundredths of a second more to clean up. > > Kyle Dawkins > Central Park Software > > On Friday 19 April 2002 11:18, Peter Bi wrote: > > If merely the last access time and number of requests within a given time > > interval are needed, I think the fastest way is to record them in a cookie, > > and check them via an access control. Unfortunately, access control is > > called before content handler, so the idea can't be used for CPU or > > bandwidth throttles. In the later cases, one has to call DB/file/memory for > > history. > > > > Peter Bi > > > > > > - Original Message - > > From: "kyle dawkins" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Friday, April 19, 2002 8:02 AM > > Subject: Re: Throttling, once again > > > > > Guys > > > > > > We also have a problem with evil clients. It's not always spiders... in > > > > fact > > > > > more often than not it's some smart-ass with a customised perl script > > > designed to screen-scrape all our data (usually to get email addresses > > > for spam purposes). > > > > > > Our solution, which works pretty well, is to have a LogHandler that > > > checks > > > > the > > > > > IP address of an incoming request and stores some information in the DB > > > > about > > > > > that client; when it was last seen, how many requests it's made in the > > > > past n > > > > > seconds, etc. It means a DB hit on every request but it's pretty light, > > > > all > > > > > things considered. > > > > > > We then have an external process that wakes up every minute or so and > > > > checks > > > > > the DB for badly-behaved clients. If it finds such clients, we get email > > > > and > > > > > the IP is written into a file that is read by mod_rewrite, which sends > > > bad clients to, well, wherever... http://www.microsoft.com is a good one > > > :-) > > > > > > It works great. Of course, mod_throttle sounds pretty cool and maybe > > > I'll test it out on our servers. There are definitely more ways to do > > > this... > > > > > > Which reminds me, you HAVE to make sure that your apache children are > > > size-limited and you have a MaxClients setting where MaxClients * > > > > SizeLimit < > > > > > Free Memory. If you don't, and you get slammed by one of these wankers, > > > > your > > > > > server will swap and then you'll lose all the benefits of shared memory > > > > that > > > > > apache and mod_perl offer us. Check the thread out that was all over the > > > list about a month ago for more information. Basically, avoid swapping > > > > at > > > > > ALL costs. > > > > > > > > > Kyle Dawkins > > > Central Park Software > > > > > > On Friday 19 April 2002 08:55, Marc Slagle wrote: > > > > We never tried mod_throttle, it might be the best solution. Also, one > > > > thing to keep in mind is that some search engines will come from > > > > multiple > > > > > > IP addresses/user-agents at once, making them more difficult to stop. > >
Re: framesets/AuthCookie question
Michael: It is great to see custom_error(). Last time, it took me a few hours in hacking the whole module. :-( > > However, I dont think it will work for his problem because his javascript code > seems to launch a NEW REQUEST, thus loosing anything that was stored away in > $r->subprocess_env(). So the only viable option is to pass the error codes in > they url (as part of the query string) I think. > An extra cookie is another solution. Peter Bi - Original Message - From: "Michael Schout" <[EMAIL PROTECTED]> To: "Peter Bi" <[EMAIL PROTECTED]> Cc: "Fran Fabrizio" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Friday, April 19, 2002 9:44 AM Subject: Re: framesets/AuthCookie question > On Wed, 17 Apr 2002, Peter Bi wrote: > > > Fran: > > > > You may need to 1) add a few lines of code in AuthCookie to make your error > > code aware to other methods, and 2) have a dynamic login page that can > > interpret the code. Alternatively, you may try AccessCookie I posted. :-) > > The CVS version of AuthCookie has a custom_errors() hook in it that does this > sort of thing. > > However, I dont think it will work for his problem because his javascript code > seems to launch a NEW REQUEST, thus loosing anything that was stored away in > $r->subprocess_env(). So the only viable option is to pass the error codes in > they url (as part of the query string) I think. > > Mike > >
Re: Throttling, once again
If merely the last access time and number of requests within a given time interval are needed, I think the fastest way is to record them in a cookie, and check them via an access control. Unfortunately, access control is called before content handler, so the idea can't be used for CPU or bandwidth throttles. In the later cases, one has to call DB/file/memory for history. Peter Bi - Original Message - From: "kyle dawkins" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, April 19, 2002 8:02 AM Subject: Re: Throttling, once again > Guys > > We also have a problem with evil clients. It's not always spiders... in fact > more often than not it's some smart-ass with a customised perl script > designed to screen-scrape all our data (usually to get email addresses for > spam purposes). > > Our solution, which works pretty well, is to have a LogHandler that checks the > IP address of an incoming request and stores some information in the DB about > that client; when it was last seen, how many requests it's made in the past n > seconds, etc. It means a DB hit on every request but it's pretty light, all > things considered. > > We then have an external process that wakes up every minute or so and checks > the DB for badly-behaved clients. If it finds such clients, we get email and > the IP is written into a file that is read by mod_rewrite, which sends bad > clients to, well, wherever... http://www.microsoft.com is a good one :-) > > It works great. Of course, mod_throttle sounds pretty cool and maybe I'll > test it out on our servers. There are definitely more ways to do this... > > Which reminds me, you HAVE to make sure that your apache children are > size-limited and you have a MaxClients setting where MaxClients * SizeLimit < > Free Memory. If you don't, and you get slammed by one of these wankers, your > server will swap and then you'll lose all the benefits of shared memory that > apache and mod_perl offer us. Check the thread out that was all over the > list about a month ago for more information. Basically, avoid swapping at > ALL costs. > > > Kyle Dawkins > Central Park Software > > On Friday 19 April 2002 08:55, Marc Slagle wrote: > > We never tried mod_throttle, it might be the best solution. Also, one > > thing to keep in mind is that some search engines will come from multiple > > IP addresses/user-agents at once, making them more difficult to stop. > >
Re: Sharing Variable Across Apache Children
What will happen if the client's DNS caches the domain name to an IP, which is then dead ? If I understand it corrently, the current system can work only if there is something like NAT in front of the machines, which dynaimcally forward each request. Won't it ? Peter Bi - Original Message - From: "Medi Montaseri" <[EMAIL PROTECTED]> To: "Andrew Ho" <[EMAIL PROTECTED]> Cc: "Benjamin Elbirt" <[EMAIL PROTECTED]>; "modperl list" <[EMAIL PROTECTED]> Sent: Wednesday, April 17, 2002 9:08 PM Subject: Re: Sharing Variable Across Apache Children > You had us going for a whileI thought you are talking about some > distributed > session management (accross different boxes) > > Another suggestion is to use lbnamed. lbnamed is a DNS server and Load > Balancing > server that listens to port 53 and resolves IPs, but on the other side of its > personality > it talks to bunch of agents who are running on workers. You get to set what > the > parameters or criteria is and assign a cost factor for a worker. lbnamed then > > distributes the work on the lightest/least cost worker. > > In this scenario, whence a box is out (or its critical piece like Oracle, or > HTTP server) > then no further work is routed to it . > > Also, be aware that using CNAME in DNS does not provide a uniform > distribution > of load. Imagine a web page having 20 images and another 5 images. You'll not > know > with good certainty that if your heavy work like database access is really > being > distributed. With CNAME you do have a chance of developing harmonics. CNAME > (aka round robin) is totally unaware of the load on the worker. Maybe that's > why > your boxes are bulking > > See http://www.stanford.edu/~schemers/docs/lbnamed/lbnamed.html > > > > Andrew Ho wrote: > > > Hello, > > > > BE>Let me explain in more detail what I'm doing. > > > > So if the situation you explain is the only reason you want a variable > > shared load balanced machines, I'd suggest a totally different way of > > doing this altogether. Best would be to use an already shared persistent > > storage mechanism (NFS or Oracle) but it looks like Oracle warnings are > > precisely what you want distinct alerts on (why are you getting so many > > Oracle errors anyway? that might be the first thing you want to check). > > > > I'm assuming the number of warning e-mails you get is less than 450,000 / > > 5 == 90,000 each day, so that if each warning e-mail were a web request, a > > single box could handle them (if more than 1/5 of your requests result in > > errors, you REALLY want to just fix the problem first). So put up a single > > webserver box to serve as an error reporter and logger. You could either > > use distributed logging (like mod_log_spread) or simpler, just set up > > another webserver that takes requests like > > /record_error.pl?error_msg=foo&remote_addr=bar or whatever. > > > > Your error handlers on your five load-balanced boxes send an HTTP request > > to this error handling box. All error e-mails can originate from this box, > > and the box can internally keep a lookup table (using any of the fine > > techniques discussed by the folks here) to avoid sending duplicate errors. > > > > In this scenario error handling is offloaded to another box, and as a > > bonus you can track the aggregate number of errors each day in an > > automated way and run reports and such (without having to count e-mails in > > your inbox). > > > > Humbly, > > > > Andrew > > > > -- > > Andrew Ho http://www.tellme.com/ [EMAIL PROTECTED] > > Engineer [EMAIL PROTECTED] Voice 650-930-9062 > > Tellme Networks, Inc. 1-800-555-TELLFax 650-930-9101 > > -- > > -- > - > Medi Montaseri [EMAIL PROTECTED] > Unix Distributed Systems EngineerHTTP://www.CyberShell.com > CyberShell Engineering > - > > >
Re: PREANNOUNCE: modperl banners project
COOOL image! (Apparently, I missed that part of discussion when I was in observational cosmology. --no kidding) Peter Bi - Original Message - From: "Stas Bekman" <[EMAIL PROTECTED]> To: "Peter Bi" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Wednesday, April 17, 2002 10:19 PM Subject: Re: PREANNOUNCE: modperl banners project > Peter Bi wrote: > > Is "mod_perl" supposed to be the final choice of the name ? Someones > > suggested before to use a different name like "Tomcat" for Java. What is the > > latest conclusion ? > > Where have you been all this time, it was cast in stone already: > http://apache.org/~stas/boulder.gif > > :) > > > __ > Stas BekmanJAm_pH --> Just Another mod_perl Hacker > http://stason.org/ mod_perl Guide ---> http://perl.apache.org > mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com > http://modperlbook.org http://apache.org http://ticketmaster.com > >
Re: framesets/AuthCookie question
Fran:
You may need to 1) add a few lines of code in AuthCookie to make your error
code aware to other methods, and 2) have a dynamic login page that can
interpret the code. Alternatively, you may try AccessCookie I posted. :-)
In AccessCookie, you simply "return $error" from authenticate(), let login
page() catch the code and display corresponding instruction. I haven't
tested it in a frame set, but it should appear a login page with custom
instructions in the last window the user visited before the expiration time.
The user re-types login/password, then is redirected to the page he tried
before.
Peter Bi
- Original Message -
From: "Fran Fabrizio" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, April 17, 2002 3:01 PM
Subject: framesets/AuthCookie question
>
> I'm using AuthCookie and as some of you know, if it determines your
> session to be invalid it redirects to a login page instead by way of a
> FORBIDDEN response coupled with a custom error page.
>
> My app has a frameset (navigation on the left, and two data frames on
> the right). I know the evils of framesets, but in our case, it's the
> best way to present our particular data.
>
> What ends up happening is that if the session expires, AuthCookie
> displays the login page inside whatever frameset you were clicking in,
> while the other two remain on whatever they were on previously.
>
> I made a quick solution...I told AuthCookie that my login page was
> login.html. login.html had javascript which called /real/login (a
> mod_perl handler) and targeted it to the top frame. All is well and now
> the entire browser window gets cleared and replaced with the login page.
>
> However...I then thought it'd be neat to include on the /real/login page
> a message to tell them how they got there ("Your session has expired",
> "Your account has logged on from another location", "Invalid
> username/password combination", whatever...).
>
> At first I thought I could accomplish this by simply doing
> $r->notes('LOGINFAILMSG' => 'Your session has expired') if AuthCookie
> detected it to be thus, and then in my handler I could retrieve it and
> display it.
>
> However, it's failing of course because I added the extra redirection of
> the login.html w/ the javascript, which makes a round trip to the client
> and back, so it looks like a brand new request to mod_perl, thus, no
> notes() any more. Is there a solution to breaking out of the frameset
> AND propagating the reason for the logout to the /real/login page?
>
> I'd appreciate and and all ideas. Thanks!
>
> -Fran
>
>
>
Re: PREANNOUNCE: modperl banners project
Is "mod_perl" supposed to be the final choice of the name ? Someones suggested before to use a different name like "Tomcat" for Java. What is the latest conclusion ? Peter Bi - Original Message - From: "Stas Bekman" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, April 16, 2002 11:54 PM Subject: PREANNOUNCE: modperl banners project > This is just a pre-announce... > > The short story: > > We need somebody to do the coordination for the modperl banners project, > similar to what Jonathan has done with the new logo creation/selection > project. > > The long story: > > We need to create a few banners, so we can use these as ads on friendly > sites. I've already one tech site that wants to advertise us for free. I > know that ads don't really work, but the targetted advertising is in a > better shape. > > I think the current market standard is 468x60 and 150x40 (pixels) and > size about 10k. It's been a long time since I was doing these myself, so > I'm not sure what's the acceptable image format. Definitely not PNG > (Since some older browsers crash on PNGs). but these can be converted to > other more back-compat formats. Anyway, the coordinator should figure > out all these details before posting the announcement, so to prevent > confusing and time wasting. > > The coordinator will accept submissions from individuals and put them > somewhere online (better pre-announce the url, so people can see the > work in progress). I don't know yet if we will need to do the voting, > but it's an option. All depends on how many banners will get submitted. > > The coordinator should post the announcement with details about what and > how to do, where to submit the banners and then after a decided > timeframe post the results back to the list. Of course we will accept > new banners in the future, but for the initial batch it'd be nice to > have some timeframe, since we already have a need. > > Eventually all the chosen banners will appear on the new mod_perl site. > Since we are very close to the transition period, we need a temp > location off-site for collecting the banners. > > Ideas for banners: > > * world domination chapter 1 (only 20% achieved) > * world domination chapter 2 (50% target) > * include the 2.0 theme > * ... > * definitely re-use the new logo > http://wypug.digital-word.com/mod_perl/winner/ > * ... > > Also I don't know if the banners can be animated or not. Someone who's > in touch with the ads bussiness these days, please help the coordinator > to fine tune the specs. > > p.s. I hope that I didn't make this simple thing sound too complicated :) > > p.p.s. could also in parallel run a T-shirt logo contest, we have a new > conference coming up in July. It's definitely a time to start thinking > about mod_perl freebies! > > p.p.p.s. You help is very appreciated! > > __ > Stas BekmanJAm_pH --> Just Another mod_perl Hacker > http://stason.org/ mod_perl Guide ---> http://perl.apache.org > mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com > http://modperlbook.org http://apache.org http://ticketmaster.com > >
Re: Enforcing user logged in from only 1 browser?
Fran: 1) agreed. If a custom login page is needed, one has to look for other solutions such as cookie access control. 2) that depends. First, for some reasons, Internet is designed without "Logout". Many seldom logout from those services such as Yahoo mail, and me too. For the specific question you posted (one login only for an account), while it can be in principle designed and implemented, in practice, it may not work that smoothly, because many users still don't run "Logout". Trust me :-). So BA or cookie doesn't matter. Second, you can make a link to close the window using javascript, just like a "Logout" button. 3) will be very interesting to hear about your successful implementation! (BTW, if only the "existence" status of an account is needed to double check, please consider a lock file (e.g. -e) under Apache::File that may be much faster than to call SessionDBI) Peter - Original Message ----- From: "Fran Fabrizio" <[EMAIL PROTECTED]> To: "Peter Bi" <[EMAIL PROTECTED]> Cc: "Jeff" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Tuesday, April 16, 2002 6:33 AM Subject: Re: Enforcing user logged in from only 1 browser? > Peter Bi wrote: > > If you touch SessionDBI for every request, why don't go directly to the > > Basic Authentication ? > > 1. You can't use a custom log in page > 2. You can't log out unless you close your browser > 3. It's for use by our employees only. They are told to enable cookies. =) > > -Fran > > > >
[ANNOUNCE Apache::AccessCookie-0.32] many new flavors
This is the second public release of the access control module. You can download it from here: http://mod_perl.home.att.net/AccessCookie_0_32.tar Besides few minor corrections from version 0.31, this one adds several ticket issuing mechanisms and the interface to implement new issuer is becoming especially easy to do. In details, here are they: 1) There is a default login page using the simply codes. Webmasters can override the page() method according to the way they like. HTML::Template is not mandatory. 2) The ticket issuer module Apache::AccessCookieMaster, which uses DBI database, is now an interface named as Apache::AccessCookie::Ticket. To actually implement an issuing mechanism, one needs to inherits it and implement his/her own authenticate() method. Arguments to accepts are: $self, this; $r, the request object; $login, the login name; $password, the login password; and $last_access, when the user got a valid ticket last time. It returns an error string or undef if the issuer authentication is successsful. 3) Currently we have implemented the following 7 issuers: DBI: authenticated against a DBI database FTP: against a FTP server (those who can login to the FTP server gets a valid ticket) IMAP: against an IMAP server LDAP: against a LDAP server NIS: again a NIS server NISPlus: against a NIS+ plus server Remote: against a remote URL which is protected by Basic Authentication. 4) Because of the limitation to test all types of servers, PLEASE NOTE that IMAP, LDAP, NIS, NIS+ are actually in the 0.01 version and should be used very carefully. If you use them, please also take a look at the following related CPAN modules: Apache::AuthCookieLDAP Apache::AuthzLDAP Apache::AuthLDAP Apache::AuthenLDAP Apache::AuthNetLDAP Apache::AuthPerLDAP Apache::AuthenIMAP Apache::AuthenN2 Apache::AuthenNIS Apache::AuthzNIS Apache::AuthenNISPlus Authen::Smb Apache::AuthenNTLM Apache::AuthenSmb Apache::AuthenURL. Please help to improve the AccessCookie modules and send me a note! 5) For those who have not checked the last release nor other modules like Apache::AuthCookie, here is a short summary as what they are. Let's take the AccessCookie::Remote as an example. The original idea of authentication against a remote URL is in Apache-AuthenURL-0.8 (by John D Groenveld.): if a visitor can login successfully to a web page that is protected by Basic Authentication, he/she will be allowed to access the current site as well. In AuthenURL, the verification is performed by LWP that has to be made for every request. In the current ticketing system, the authentication is against a valid self-consistent ticket, a MD5 hash. If the visitor has no ticket, he/she is first redirected to the ticket master machine for getting a ticket. The ticket master (issuer) runs the module Apache::AccessCookie::Remote. It checks the credentials against the remote URL. If it passes, the master will issue a self-consistent ticket so the user can use the ticket for the following up requests within a limited time period. There is no need to verify against the remote URL every time. This should boost the speed very much. Peter Bi [EMAIL PROTECTED] Feb. 15, 2002
Re: Enforcing user logged in from only 1 browser?
If you touch SessionDBI for every request, why don't go directly to the
Basic Authentication ? Using AuthCookie would 1) slow down the
authentication process (because an extra MD5 hash calculation) and 2) drop
off 10% of users who have disabled the cookie.
One of the nice features in the AuthCookie, and ticketing authentication
systems in general, is that the ticket is self-consistent. So one can check
if the ticket is valid without calling any DBI (instead, it calculates a
MD5). Repeating SELECTs/UPDATEs to DBI does hurt much the performance of a
high traffic site.
My 2 cents.
Peter Bi
[EMAIL PROTECTED]
>>>>..
> If someone comes in with an old active session (assuming it's not
> expired) AuthCookie examines the MD5 hash and says "everything matches
> up, you may proceed". I need to add a step here to say "if newer
> session for user exists, kill this one". But you've just given me a
> great idea! When the old session comes in, there will still be data in
> the session (because the new session is using it - sessions are keyed by
> user id, not session id). So I can't rely on an empty session data to
> be the clue. BUT - I can store the session key that generated this
> session data in with the session data, and try to match those up. I
> like it. This will work, I think. Thank you. =) Why do I use the user
> id instead of the session id for the session key? Because it makes the
> code easier for other developers ("a user will always have a session
> with the key $r->connection->user") and that gets passed around
> automatically rather than me having to expose the developers to the
> AuthCookieDBI cookie directly. I just find it easier to rely on
> $r->connection->user to always be the session key.
>
>>>>>>
Re: Enforcing user logged in from only 1 browser?
To make a perfect system like this probably needs users to sign-off faithfully by every session. Peter Bi - Original Message - From: "Fran Fabrizio" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, April 12, 2002 1:22 PM Subject: Enforcing user logged in from only 1 browser? > > Hello all, > > I'm looking for a straightforward approach to extend our AuthCookie > sessioning to enforce that a user is only logged in from one browser at > a time. For us, it would suffice that if the user tries to log in from > a 2nd browser, the first session would just be expired. > > I was thinking that upon login I could save the AuthCookie key in that > user's db entry as current_session_key and I could blank it out when > they explicitly log out. Then during login, I would be able to see if > there's another key still out there for them. The tricky part for me is > figuring out if that key is still an -active- session as opposed to > having just left their browser open last night or something. And also, > if I do determine that it is another active one, how would I expire it? > > Anyone done this type of thing previously? > > Thanks, > Fran > >
Re: Newbie Alert: Q: References to Authenticating a User to MS-SQL 2000?
Darren: you can subclass the authentication() method in the module AccessCookieMaster.pm I posted just a hour ago, if you won't mind asking your users enable cookies. ie: replacing "select 1 from url_user.table where username='username' and password='password'" by "select 1 from ... AND url='$request_uri'" For better control, you may need to double check the URL each time in AccessCookie.pm Peter Bi [EMAIL PROTECTED] - Original Message - From: "Darren Ward" <[EMAIL PROTECTED]> To: "Apache-Perl (E-mail)" <[EMAIL PROTECTED]> Sent: Monday, April 08, 2002 4:49 PM Subject: Newbie Alert: Q: References to Authenticating a User to MS-SQL 2000? > Hi All, > > Subject line says it all really. > > I have a need to authenticate users against a MS-SQL 2000 Server which has a > table with 'username' and 'password' fields but also on the Apache side need > to be able to use a third field in the table 'url' to control what url's the > user can access. > > The url field would be a one to many to the username. > > Any ideas? > > Darren Ward (PGradCS, CCIE #8245, CCNP, CCDP, MCP) > Victorian Operations Manager > Mobile: 0411 750 418 > Email: [EMAIL PROTECTED] > PGP Key: http://lithium.nttaus.com.au/~darrenw/darrenw.asc > PGP Fingerprint: A4F9 3E93 4EE2 9CDF 5436 06EF 41B8 6027 4505 AE48 > > NTT Australia IP Pty Ltd > ABN 73 080 394 645 > Level M1, Rialto Towers > 525 Collins Street, VIC. 3000 > Tel: (03) 9683 0007 > Fax: (03) 9620 7497 > http://www.nttaus.com.au/IP/ > -- -- > - > Australian General Telecommunications Carrier License No 23 > -- -- > - > Disclaimer: > Please note that this correspondence is for the named > person's use only and may contain information that is > confidential and privileged. > > If you received this correspondence in error, please > immediately delete it from your system and notify > the sender. Please ensure that you do not disclose, > copy or rely on any part of this correspondence if > you are not the intended recipient. We apologise for > any inconvenience and thank you for your assistance. > >
[announce] Apache::AccessCookie --- cookie based access control
Download the module from here: http://mod_perl.home.att.net I used Apache::AuthCookie for a long time until Netscape 6.2 came out. AuthCookie caches the login screen as the first redirecting URL even when the user successfully logs in. I then tried to make some changes in the module, and to add extra features... Finally, there seemed too many changes and the cookie control wheel, Apache::AccessCookie, is reinvented. This module is especially clean, having less than 120 lines of code. Yet, it contains almost all the features you may find in the Eagle book and Apache::AuthCookie. It follows the idea in the Eagle book to implement the control as an Access Handler only. If one needs group Authorization, one may still need AuthCookie. Some extra features are: 1) it checks if browser accepts cookie AT THE FIRST PLACE. 2) it separates the mod_perl code from the HTML login form and error reports by a HTML::Template file which webmasters can design separately to fit to their own graphic styles. The error reports include: a) ERROR_COOKIE: the browser did not accept cookies b) NO_TICKET:sign-in please c) BAD_LOGIN:user or password wrong d) BLOCK_ACCESS: more than 'max' failed trials in a day and the ip is blocked 3) optionally, it can block further authentication if one fails too many time. In addition, a 30-day hidden cookie is introduced, so a valid user can actually try unlimited times if he has a successful login within the last 30 days (he won't go crazy for the intolerance :-) plus the following standard ticketing features: 4) it is a ticket system: a group of machines can be authenticated by the same ticket providing they are under the same top domain name. 5) it is more secure than the Basic Authentication since web visitor's password is transferred only once onto the ticket master machine. 6) if authenticated against a database, the ticket system is usually fast because the verification procedure does not need database connection. 7) it "simulates" the Basic Authentication, i.e. you get username in the log file and in the later Apache phases via $r->connection->user() NOTE: this is the first public release of the module. Anyway, it runs well on our machines. Suggestions and bug reports are very welcome. Please send them to [EMAIL PROTECTED] Peter Bi Greetingland, LLC [EMAIL PROTECTED]
modifying apache config at runtime
Is is possible to modify the in-memory apache configuration at runtime? I've seen modules that allow you to parse and modify the httpd.conf file, but that's not really what I'm looking for. In particular I want to set the value of ErrorDocument. Thanks, Peter Beardsley Appropriate Solutions, Inc. [EMAIL PROTECTED]
response code under Apache::Registry?
This is kind of a bizarre question, but I was wondering if it was technically possible to set the response code of a script running under Apache::Registry. The way I usually see it being set is the return value of the handler routine, but is there any way to set it? Peter Beardsley Appropriate Solutions, Inc. [EMAIL PROTECTED]
[ANNOUNCE] Cache::Mmap 0.04
file: $CPAN/authors/id/P/PM/PMH/Cache-Mmap-0.04.tar.gz size: 14113 bytes md5: 649bdb9816f4177c0eb81c077fd7614c Much to my dismay and embarrassment, the serious bug fix in version 0.03 introduced a serious bug of it's own. You'll be pleased to hear that I've added a test suite (currently only one file) to the distribution, so this sort of thing should happen less in the future. Again, I strongly advise all users to upgrade to this version. I've also removed all the older versions from CPAN, just in case. This version also does the file locking in XS, thus removing the assumptions about struct flock's layout. It also does its own mmap()ing in XS, removing the dependency on Malcom Beattie's Mmap.pm. This means that people don't need to figure out Malcom's slightly strange distribution name, and it compiles on 5.6 without any problems (I've tested it on 5.004_05 too). >From the README: This module provides a shared cache, using a memory mapped file. Very useful for mod_perl applications. If routines are provided which interact with the underlying data, access to the cache is completely transparent, and the module handles all the details of refreshing cache contents, and updating underlying data, if necessary. -- Peter Haworth [EMAIL PROTECTED] "I don't know what kinds of evil I've done in the past. I don't even want to know. I just want that evil to carry on having its good effects" -- Damian Conway on his use of pack/unpack/vec
[ANNOUNCE] Cache::Mmap 0.03
file: $CPAN/authors/id/P/PM/PMH/Cache-Mmap-0.03.tar.gz
size: 9454 bytes
md5: f28df3400f28b54034a8a684a8e1e923
I strongly advise all users of this module to upgrade to this version if
they are using the write() method, and at least version 0.02 otherwise.
The next version should come out within the next week or so, and will remove
the dependency on Mmap.pm, and use more portable file locking.
>From the README:
This module provides a shared cache, using a memory mapped file. Very useful
for mod_perl applications. If routines are provided which interact with the
underlying data, access to the cache is completely transparent, and the module
handles all the details of refreshing cache contents, and updating underlying
data, if necessary.
Changes since version 0.02
Fixed serious bug in write(), which corrupted the cache file when replacing
already existing entries
Changes since version 0.01
Fixed serious bug in read(), which didn't update the current bucket content
size when expiring entries. This caused infinite loops in _find() and
_insert(), which have also been fixed, should anything else ever go wrong
in a similar way
--
Peter Haworth [EMAIL PROTECTED]
"Besides, I wasn't trying to help them understand.
I was only trying to help them think they understand."
-- Larry Wall
Re: Cookie authentication
On 15 Nov 2001, at 12:16, Andrew Ho wrote: > CD>It seems you can't do anything online without having cookies turned on > CD>(yahoo, bankone, huntington, ebay, etrade ) and I think internet users > CD>have accepted this. > Methinks there is a need to write a transparent "store cookies on URL" > module. I seem to recall at least one major Apache module having an option > to use URL-based authentication instead of cookie-based... but I can't > seem to find that from a cursory perusal of CPAN. http://perl.apache.org/guide/modules.html#Apache_Session_Maintain_sessi I used Apache::Session and HTML::Template to embed the session_id in the url in a recent job site.I planned this before I built the site (all templates built according to the plan :). No problems there. There were no static pages. I find cookies are used when one has a site static/dynamic pages. How do you keep a user if they click to a static page? I don't know. But one should always check if a user has cookies turned on. I recall an internal site I did for FedEx a few years back and I used cookies for it as it was before my mod_perl use. Well it turned out that the vice-president had cookies turned off. He was not a customer we wanted to ignore:) Peter "A government that robs Peter to pay Paul can always depend upon the support of Paul." -- George Bernard Shaw
Re: cgi-object not cacheable
On Wed, Nov 14, 2001 at 10:39:36AM -0500, Perrin Harkins wrote:
> > its definitely running under mod_perl. But imho the time it takes to
> > create a new cgi-object should not depend too much wheter its running
> > under mod_perl or not, cause the CGI-module is loaded before. (In fact
> > I load in httpd.conf using PerlModule-Directive)
>
> If it was running under CGI, it would be compiling CGI.pm on each request,
> which I've seen take .3 seconds. Taking that long just to create the new
> CGI instance seems unusual. How did you time it? Are you using
> Apache::DProf?
>
Wouldnt it be compiled at the use-statement ? I timed it using
module-internal loggingfunction which use time::hires.
> > This makes very much sense. Apache::DBI does not limit the number of
> > persistent connections. It just keeps all the connections open per
> > apache-process.
>
> That should mean one connection per process if you're connecting with the
> same parameters every time.
>
in my case it means up to 4 connections per process, cause in fact it
is not one module but 2 (input and output) and each needs to handle 2 different
connections.
> > if (exists($ptr->{global}->{dbhandles}->{_some_id_string}))
>
> You know that this is only for one process, right? If you limit this cache
> to 20 connections, you may get hundreds of connections.
>
yes, thats why I limit it to 1 or even 0.
> > I would prefer to handle this in a special pooling-module
> > like Apache::DBI is, but where one can specify a maximum number of
> > open connections and a timeout per connection (connection will be
> > terminated after it was not used a specified amount of time).
>
> You can just set a timeout in your database server. If a connection times
> out and then needs to be used, the ping will fail and Apache::DBI will
> re-connect.
thats an interesting idea. I experienced crashes on ping to dead
connections under DBD::Pg but this is worth to check.
>
> > As soon
> > as I get IPC::Sharable to work I'll consider writing such a thingy.
>
> You can't share database handles over IPC::Shareable, but you could share a
> global number tracking how many total database handles exist. However, I
> think you'd be better off using Apache::DBI and limiting the number of
> Apache children to the number of connections your database can deal with.
>
I hope to share databasehandles via IPC. One has to avoid that only
one process writes to a handle at the same time !! (hope I'm right
here) This would offer possibilities to create a pool of handles with
limited max. number and clientsided timeouts. If a process requests a
handle and there is one cached in the pool it will give this handle
back. Otherwise it will create a new handle or - if max. number is
reached - return 0. The calling application can then decide to print
an excuse due to the user 'cause we are so popular we cant server you
:)' or create and destroy a temporary handle to process the request.
This would be something I would actually prefer to Apache::DBI, but I
dont know if its possible, but I'll try. Such a thing would be very
important, especially on slow servers with less ram, where Apache::DBI
opens to many connections in peak-times and leaves the system in a bad
condition ('to many open filehandles')
peter
ps: just if one is interested: today I was very happy to wear a helmet
when I crashed with my bike ;) At least I can write this lines after
my head touched the road. (well : it hurts in the arms when writing
fast ;)
--
mag. peter pilsl
phone: +43 676 3574035
fax : +43 676 3546512
email: [EMAIL PROTECTED]
sms : [EMAIL PROTECTED]
pgp-key available
Re: cgi-object not cacheable
On Tue, Nov 13, 2001 at 09:18:04PM -0500, Perrin Harkins wrote:
> > One run of my script takes about 2 seconds. This includes a lot of
> > database-queries, calculations and so on. about 0.3 seconds are used
> > just for one command: $query=new CGI;
>
> That's really awfully slow. Are you positive it's running under mod_perl?
> Have you considered using Apache::Request instead of CGI.pm?
>
its definitely running under mod_perl. But imho the time it takes to
create a new cgi-object should not depend too much wheter its running
under mod_perl or not, cause the CGI-module is loaded before. (In fact
I load in httpd.conf using PerlModule-Directive)
> > This is not a problem of my persistent variables, cause this works
> > with many other objects like db-handles (cant use Apache::DBI cause
> > this keeps to many handles opened, so I need to cache and pool on my
> > own), filehandles etc.
>
> Whoa, you can't use Apache::DBI but you can cache database handles yourself?
> That doesn't make any sense. What are you doing in your caching that's
> different from what Apache::DBI does?
This makes very much sense. Apache::DBI does not limit the number of
persistent connections. It just keeps all the connections open per
apache-process. This will sum up to about 20 open
database-connections, each having one postgres-client running 'idle in
transaction' - and my old small serversystem is going weak. So I cant
cache all connections, but only a limited number and so I cache on my
own :) Beside: it is done with a few lines of code, so it wasnt much
work either:
if (exists($ptr->{global}->{dbhandles}->{_some_id_string}))
{
$dbh=$ptr->{global}->{dbhandles}->{_some_id_string};
$dbh or err($ptr,19); # there must have been something wrong internally
if (not $dbh->ping) {$connect=1;$r='reconnect'} # we just reconnect ..
$dbh and $dbh->rollback; # this issue a new begin-transaction and avoid several
problem with 'current_timestamp' that dedlivers the value
# of the time at the beginning of the transaction,
even if this is hours ago. see TROUBLEREPORT1
$r= "stored" if $r eq '-';
} else {$connect=1;}
if ($connect)
{
$dbh=DBI->connect(connectinformation)
}
and on exit I just disconnect all handles but keeping a specified
amount. I would prefer to handle this in a special pooling-module
like Apache::DBI is, but where one can specify a maximum number of
open connections and a timeout per connection (connection will be
terminated after it was not used a specified amount of time). As soon
as I get IPC::Sharable to work I'll consider writing such a thingy.
best,
peter
--
mag. peter pilsl
phone: +43 676 3574035
fax : +43 676 3546512
email: [EMAIL PROTECTED]
sms : [EMAIL PROTECTED]
pgp-key available
cgi-object not cacheable
One run of my script takes about 2 seconds. This includes a lot of database-queries, calculations and so on. about 0.3 seconds are used just for one command: $query=new CGI; I tried to cache the retrieved object between several requests by storing to a persistent variable to avoid this long time, but it is not cacheable. (in the meaning of : operations on a cached CGI-object will just produce nothing) This is not a problem of my persistent variables, cause this works with many other objects like db-handles (cant use Apache::DBI cause this keeps to many handles opened, so I need to cache and pool on my own), filehandles etc. any idea ? thnx, peter -- mag. peter pilsl phone: +43 676 3574035 fax : +43 676 3546512 email: [EMAIL PROTECTED] sms : [EMAIL PROTECTED] pgp-key available
dont understand mem-mapping
I just cant get the following in my brain. I have a modules that is
started with apache using the PerlModule-directive in httpd.conf.
This module defines a global pointer on startup that should be the
same in all sub-instances of httpd and really in the current
apache-session all instances print out : $g_ptr : HASH(0x8458a30)
This hashpointer is later filled with different values (dbhandles,
filehandles ...) that should kept open over more calls.
Now each session has the same pointer, but the content of the
anonymous hash its pointing too is different in each instance !!
thread 1:
$g_ptr : HASH(0x8458a30)
$g_ptr->{counter} : SCALAR(0x85aa62c)
thread 2:
$g_ptr : HASH(0x8458a30)
$g_ptr->{counter} : SCALAR(0x85f5e2c)
A even more strange example is an anonmous array that has the same
adress, but different content too.
The only explanation is that there is some mem-mapping for each
httpd-instance, but I dont know much about this.
My problem now is, that each httpd-instance opens a lot of db-handles
and connections and I end up with system-errors 'to many files opened'
or such things.
Is there any way to share handles between all instances (I guess not,
and I'm sure this mem-mapping has a deeper meaning too: if more than
one instance access the same adress at the same time there would be
lot of troubles and I'm even more sure that this has something to do
with the copy-on-write feature of fork(), but I'm just not good in
this things, so I'd like to have some comment to be sure that this is
a principal problem and not a problem of my module)
thnx,
peter
--
mag. peter pilsl
phone: +43 676 3574035
fax : +43 676 3546512
email: [EMAIL PROTECTED]
sms : [EMAIL PROTECTED]
pgp-key available
