What's not supported?
Hiya all, I'm putting together a new box to migrate an old server over to. The existing server is running Apache 2.0.55 with mod_perl and mod_php. I'm looking at putting 2.2.8 on the new box, but the documentation is a little... lacking... in one area: "Apache 2.0 is fully supported. Most of Apache 2.2 is supported, and work toward full support is underway." Erm... so what's NOT supported? Are there things that exist in Apache 2.0 that also exist in Apache 2.2 but aren't supported? Or are the only things not supported *new* things for 2.2? It's important to know not only that most 2.2 features are supported, but which are not, and the docs don't say a word on this that I can see. I Googled for it, too, but to no avail. All I could find relevant were links back to the What Is Mod Perl page and that text up there. I guess it comes down to: If I have an existing site built using mod_perl on 2.0 and I make a new server running 2.2 and migrate my code over, is it goung to work? Most of it is either pure mod_perl handlers, registry scripts, and output filters (both SSI and a custom one I use to "wrap" my layout around script output based on extension). Anyhow, just wondering. Thanks -- Dodger
Re: some flawed benchmarks
Oh. I would also recommend three variants, based on what people often
do, what people sometimes do, and what people probably should do when
using CGI.pm, which can make a difference (just for thoroughness):
Usually done:
#!/usr/bin/perl
use CGI;
print header;
print <<"EOF";
Environment dump:
@{[map "$_\n$ENV{$_}\n", sort keys %ENV]}
EOF
Sometimes do:
#!/usr/bin/perl
use strict;
use CGI;
my $cgi = new CGI;
print $cgi->header;
print <<"EOF";
Environment dump:
@{[map "$_\n$ENV{$_}\n", sort keys %ENV]}
EOF
Might do occassionally, and probably should do all the time if using CGI:
#!/usr/bin/perl
use strict;
use CGI(); # note the difference -- using CGI in OO mode, don't import
*anything*
my $cgi = new CGI;
print $cgi->header;
print <<"EOF";
Environment dump:
@{[map "$_\n$ENV{$_}\n", sort keys %ENV]}
EOF
2008/7/9 <[EMAIL PROTECTED]>:
> A couple of months ago i was going through slides from gozers "From CGI to
> mod_perl 2.0, Fast!" talk, which has some benchmarks comparing CGI, perlrun
> and registry to each other. At which point i realized that i've never
> really known how much faster using straight handlers is than using one of
> the CGI emulation layers. I also didn't have any idea how much faster
> SetHandler modperl was vs SetHandler perl-script.
>
> So i decided to see what i could figure out. I took gozers CGI from the
> slides (slightly modified) and ran it through the paces on my laptop, then
> converted the script to run as a straight handler.
>
> here's the CGI version:
>
> #!/usr/bin/perl
>
>
> print qq[Content-Type: text/html\r\n\r\n];
>
> print(qq[
>
> Hello Worlds
>
> GATEWAY_INTERFACE: $ENV{GATEWAY_INTERFACE}
> MOD_PERL: $ENV{MOD_PERL}
>
>
>
> ]);
>
>
> Here's the Handler version
>
> package Kabob::HelloWorld;
>
> use strict;
> use warnings;
>
> use Apache2::RequestRec ();
>
> use Apache2::Const -compile =>qw(:common);
>
> sub handler {
>my $r = shift;
>
>$r->content_type('text/html');
>$r->print(qq[
>
> Hello Worlds
>
> GATEWAY_INTERFACE: $ENV{GATEWAY_INTERFACE}
> MOD_PERL: $ENV{MOD_PERL}
>
>
>
>
>]);
>
>return Apache2::Const::OK;
> }
>
> 1;
>
> and here's the conf (these tests were all running through a light mod_proxy
> front end too)
>
>
>
>
>ProxyPass http://localhost:8080/cgi/
>ProxyPassReverse http://localhost:8080/cgi/
>
>
>
>ScriptAlias /cgi/ /www/p/
>
>
>
>Alias /perlrun/ /www/p/
>
>
>ProxyPass http://localhost:8080/perlrun/
>ProxyPassReverse http://localhost:8080/perlrun/
>
>
>SetHandler perl-script
>PerlHandler ModPerl::PerlRun
>Options +ExecCGI
>PerlSendHeader On
>
>
>
>Alias /registry/ /www/p/
>
>
>ProxyPass http://localhost:8080/registry/
>ProxyPassReverse http://localhost:8080/registry/
>
>
>SetHandler perl-script
>PerlHandler ModPerl::Registry
>Options +ExecCGI
>PerlSendHeader On
>
>
>
>
>
>
>
>ProxyPass http://localhost:8080/perlscript/
>ProxyPassReverse http://localhost:8080/perlscript/
>
>
>SetHandler perl-script
>PerlResponseHandler Kabob::HelloWorld
>
>
>
>
>
>ProxyPass http://localhost:8080/modperl/
>ProxyPassReverse http://localhost:8080/modperl/
>
>
>SetHandler modperl
>PerlResponseHandler Kabob::HelloWorld
>
>
>
>
> and here's the results (which are no doubt flawed for a number of reasons)
>
> running: ab -n 1 [url]
>
> CGI
> Requests per second:217.80 [#/sec] (mean)
> Time per request: 4.591 [ms] (mean)
> Transfer rate: 53.17 [Kbytes/sec] received
>
> PerlRun
> Requests per second:482.49 [#/sec] (mean)
> Time per request: 2.073 [ms] (mean)
> Transfer rate: 114.49 [Kbytes/sec] received
>
> Registry
> Requests per second:693.33 [#/sec] (mean)
> Time per request: 1.442 [ms] (mean)
> Transfer rate: 164.53 [Kbytes/sec] received
>
> SetHandler perl-script
> Requests per second:772.12 [#/sec] (mean)
> Time per request: 1.295 [ms] (mean)
> Transfer rate: 189.94 [Kbytes/sec] received
>
> SetHandler modperl
> Requests per second:1048.66 [#/sec] (mean)
> Time per request: 0.954 [ms] (mean)
> Transfer rate: 250.84 [Kbytes/sec] received
>
> I'm not sure how well you can really compare the CGI emulation numbers to
> the PerlHandler numbers, but personally i think the 30%ish improvement from
> perl-script to modperl is pretty amazing. I wouldn't have imagined it would
> have been that high.
>
> Adam
>
>
>
>
>
>
>
>
>
--
Dodger
Re: some flawed benchmarks
I appreciate this, as I'd been wondering.
But it also prompts me to.. I gotta ask...
No offence but...
Don't you know what a here_doc is?
--
Dodger
2008/7/9 <[EMAIL PROTECTED]>:
> A couple of months ago i was going through slides from gozers "From CGI to
> mod_perl 2.0, Fast!" talk, which has some benchmarks comparing CGI, perlrun
> and registry to each other. At which point i realized that i've never
> really known how much faster using straight handlers is than using one of
> the CGI emulation layers. I also didn't have any idea how much faster
> SetHandler modperl was vs SetHandler perl-script.
>
> So i decided to see what i could figure out. I took gozers CGI from the
> slides (slightly modified) and ran it through the paces on my laptop, then
> converted the script to run as a straight handler.
>
> here's the CGI version:
>
> #!/usr/bin/perl
>
>
> print qq[Content-Type: text/html\r\n\r\n];
>
> print(qq[
>
> Hello Worlds
>
> GATEWAY_INTERFACE: $ENV{GATEWAY_INTERFACE}
> MOD_PERL: $ENV{MOD_PERL}
>
>
>
> ]);
>
>
> Here's the Handler version
>
> package Kabob::HelloWorld;
>
> use strict;
> use warnings;
>
> use Apache2::RequestRec ();
>
> use Apache2::Const -compile =>qw(:common);
>
> sub handler {
>my $r = shift;
>
>$r->content_type('text/html');
>$r->print(qq[
>
> Hello Worlds
>
> GATEWAY_INTERFACE: $ENV{GATEWAY_INTERFACE}
> MOD_PERL: $ENV{MOD_PERL}
>
>
>
>
>]);
>
>return Apache2::Const::OK;
> }
>
> 1;
>
> and here's the conf (these tests were all running through a light mod_proxy
> front end too)
>
>
>
>
>ProxyPass http://localhost:8080/cgi/
>ProxyPassReverse http://localhost:8080/cgi/
>
>
>
>ScriptAlias /cgi/ /www/p/
>
>
>
>Alias /perlrun/ /www/p/
>
>
>ProxyPass http://localhost:8080/perlrun/
>ProxyPassReverse http://localhost:8080/perlrun/
>
>
>SetHandler perl-script
>PerlHandler ModPerl::PerlRun
>Options +ExecCGI
>PerlSendHeader On
>
>
>
>Alias /registry/ /www/p/
>
>
>ProxyPass http://localhost:8080/registry/
>ProxyPassReverse http://localhost:8080/registry/
>
>
>SetHandler perl-script
>PerlHandler ModPerl::Registry
>Options +ExecCGI
>PerlSendHeader On
>
>
>
>
>
>
>
>ProxyPass http://localhost:8080/perlscript/
>ProxyPassReverse http://localhost:8080/perlscript/
>
>
>SetHandler perl-script
>PerlResponseHandler Kabob::HelloWorld
>
>
>
>
>
>ProxyPass http://localhost:8080/modperl/
>ProxyPassReverse http://localhost:8080/modperl/
>
>
>SetHandler modperl
>PerlResponseHandler Kabob::HelloWorld
>
>
>
>
> and here's the results (which are no doubt flawed for a number of reasons)
>
> running: ab -n 1 [url]
>
> CGI
> Requests per second:217.80 [#/sec] (mean)
> Time per request: 4.591 [ms] (mean)
> Transfer rate: 53.17 [Kbytes/sec] received
>
> PerlRun
> Requests per second:482.49 [#/sec] (mean)
> Time per request: 2.073 [ms] (mean)
> Transfer rate: 114.49 [Kbytes/sec] received
>
> Registry
> Requests per second:693.33 [#/sec] (mean)
> Time per request: 1.442 [ms] (mean)
> Transfer rate: 164.53 [Kbytes/sec] received
>
> SetHandler perl-script
> Requests per second:772.12 [#/sec] (mean)
> Time per request: 1.295 [ms] (mean)
> Transfer rate: 189.94 [Kbytes/sec] received
>
> SetHandler modperl
> Requests per second:1048.66 [#/sec] (mean)
> Time per request: 0.954 [ms] (mean)
> Transfer rate: 250.84 [Kbytes/sec] received
>
> I'm not sure how well you can really compare the CGI emulation numbers to
> the PerlHandler numbers, but personally i think the 30%ish improvement from
> perl-script to modperl is pretty amazing. I wouldn't have imagined it would
> have been that high.
>
> Adam
>
>
>
>
>
>
>
>
>
--
Dodger
Re: graphics in perl
Uhm, dude... a Perl module won't do that because Perl is a language, not a display technology. You're looking for something like Shockwave Flash. Though you can certainly have Perl generate everything. 2008/6/22 Malka Cymbalista <[EMAIL PROTECTED]>: > We are running perl 5.8.5 on a Linux machine that is running apache 2.2.6 > with mod_perl 2.0.3. Our data is in a MySQL database (MySQL 5.0.45) > > We have been asked to write a web application that requires plotting > capabilities. We do most of our web programming in perl so I am looking for > a perl module that has the following features: > 1. ability to create histograms > 2. ability to create x,y plots > 3. ability to zoom in on a portion of the graph > 4. ability to calculate the distance between 2 points on the graph > 5. ability to hover on a point and bring up some text > > Does anyone have any suggestions for which perl modules we should look into? > > Thanks for any information. > > > -- > > Malka Cymbalista > Webmaster, Weizmann Institute of Science > [EMAIL PROTECTED] > 08-934-3036 > > > > > -- Dodger
Re: mod_perl2 newbie DBI question
2008/6/12 Michael Peters <[EMAIL PROTECTED]>:
> Brian Gaber wrote:
>> # Determine MySQL locks table name
>> my $sth = $dbh->prepare("SELECT * FROM region_props WHERE region =
>> '$region'");
>> $sth->execute();
> Btw, this is *really* bad security wise. $region is coming straight from the
> browser. You're setting yourself up for an SQL Injection attack. Imagine I
> request some URL like:
> regDelLocks.pl?region= %27blah%27%3B+DROP+ALL+DATABASES
> Guess what will happen? Preventing this is really easy. Just use SQL bind
> params.
> my $sth = $dbh->prepare("SELECT * FROM region_props WHERE region = ?");
> $sth->execute($region);
Hear hear!
It can be true that sometimes you can't (or have good reason to not
want to) use placeholders.
For instance,it's feasible to build a totally dynamic query by pushing
whereclauses into an array and values into another array.
It's also feasible to build a variable length IN() list against some
array like, for instance, "WHERE colname IN(@{[(join ', ', '?' x
scalar @yourarray]}" into the statement (or using a sprintf much the
same way), it often doesn't read well.
In those cases it's understandable that you'd want to build your query
dynamically, but there's no excuse for unsafeness!
Examples:
Placeholders:
my @things_to_check_for = qw(foo bar baz luhrman);
my $q = <<"EOF";
SELECT thingy
FROM doohickeys
WHERE type IN(@{[join ', ', ('?') x scalar @things_to_check_for]})
EOF
my $st = $dbh->prepare($q);
$st->execute(@things_to_check_for);
# if the @{[]} boggles you
my @things_to_check_for = qw(foo bar baz luhrman);
my $q = sprintf <<"EOF", join ', ', ('?') x scalar @things_to_check_for;
SELECT thingy
FROM doohickeys
WHERE type IN(%s)
EOF
my $st = $dbh->prepare($q);
$st->execute(@things_to_check_for);
# More explictly:
my @things_to_check_for = qw(foo bar baz luhrman);
my $things_to_check_for = join ', ', ('?') x scalar @things_to_check_for;
my $q = sprintf <<"EOF";
SELECT thingy
FROM doohickeys
WHERE type IN($things_to_check_for)
EOF
my $st = $dbh->prepare($q);
$st->execute(@things_to_check_for);
This is a rather contrived example using a very simple query however.
Getting more complex than that, or if you're pandering to PHP
programmers (who are used to their crap database interfaces that only
let you use bind variables on input if you intend to use them on
output too, for no apparent reason), you have potential reasons to
directly create your statement (also, it makes it easier to spit out a
runnable query for debugging, because you can just print the very
statement out*).
So use DBI's quote() method:
Safe without placeholders:
my @things_to_check_for = qw(foo bar baz luhrman);
my $q = <<"EOF";
SELECT thingy
FROM doohickeys
WHERE type IN(@{[join ', ', map $dbh->quote($_), @things_to_check_for]})
EOF
(if you are using placeholders everywhere, quote can still be useful
for debugging, assuming you are ONLY using placeholders or at the very
least not writing any statements with a literal question mark in
them). You can take your statement with placeholders and do this:
my $rows = $st->execute($value1, $value2, $value3);
unless ($rows) {
my $show_query = $q;
$show_query =~ s/\?/\%s/g;
printf <<"EOF", $st->errstr, map $dbh->quote($_), $value1, $value2, $value3;
SQL Statement failed: %s
$show_query
EOF
}
--
Dodger
Re: [OT] is there a maximum output character length ?
If you have a reason to leave it open, you can always set autoflush on the file. open FO, ">file_out"; my $was = select FO; local $| = 1; select $was; print FO "a"; print FO "b"; etc. 2008/5/21 John ORourke <[EMAIL PROTECTED]>: > > Well thanks! Under regular CGI, every time your browser requests a page, > Apache has to find your script, load Perl, compile your script and any > modules you use, run it, and exit Perl. Under mod_perl, all the loading and > compiling is done when Apache starts, not on every request - it's doing far > less work. There's a lot of good info on http://perl.apache.org/ but I know > what it's like when you're too busy debugging to RTFM :) > > > > Yeah, I have read a lot of those things that you wrote many times in > peal.apache.org but I just don't know what is the specific relation to > why it never write the file completely ! > > > It's just how operating systems work - to speed things up, when you write to > the file you're actually writing to a buffer in memory. When the buffer > gets full (usually a few kB), the operating system will write it all out to > the disk. If you close the file, it will also write it all out the disk. > It's simply good practice to tidy up before you quit your program - > previously you were relying on perl to do this for you, because it's good > like that. > > cheers > John > > @ list, ! $| ;) > -- > > -- Dodger
Re: Initialize object permanently
2008/5/19 Michael Peters <[EMAIL PROTECTED]>:
> william wrote:
>
>> Then I would need to modify the QueryData module then,
>
> No don't do that.
>
>> by modifying
>> the standard module would it make my future maintenance more
>> complicated ?
>
> Absolutely.
>
>> Do you have any tips for me ?
>
> Wrap the object in your own package. Let's call it My::QueryData.
>
> package My::QueryData;
> use QueryData;
>
> my $query_data;
> sub create {
> $query_data = QueryData->new(...);
> }
>
> sub get {
> return $query_data;
> }
>
For extra syntactic sugar, you could always just do it singlet style.
package My::QueryData;
use base QueryData;
our $singlet;
sub new {
return $singlet if $singlet;
return $singlet = QueryData->new(@_);
}
Of course, if you want to allow different ones for different
invocations (i.e. Pkg->new(foo => 1) and Pkg->new(foo => 2), you can
make $singlet a hashref keyed by those options, instead, and check for
the appropriate one
Custom authentication (weird)
Heya, I'd like to implement a custom authentication without authentication. Seeing as I don't see anything about what I want to do in the normal auth stuff, I figure I will need to do mod_perl. I can get this all on my own if need be, but if someone else has already invented this wheel and wants to make a pointer or two, I'd be fine with it. Here's what I'm looking to have happen: the user gets a login box the user types in anything they want the user types in the same thing as a password there's no actual checking. Basically, I want to make people say who they are. I don't care if they lie, and they aren't likely to, as long as they type something in. It's not critical or any real need for security. It's just that I have something that's going to be free anyway that I want to give some beta testers and prerelease developers access to, but I'd like to know *which* of them have grabbed a copy, and I trust them to put in the right username because, well... ehh, they're smart enough to and it doesn't affect anything if they don't. It'll just let me check the server logs (which I drop into MySQL anyway) and check the user in the log and, if I have their email address in another table, and things have been updated since they last grabbed a copy, mail them and let them know. Basdically, I want to be able to say "Oh, Jim needs a copy of this" -- automatically or manually -- without having to search for what I remember Jim's IP to be. Make sense? It's just to get the username into the log. -- Dodger
Re: OffTopic (slightly) - Module Feedback Wanted - Authen::Ticketless
On 13/11/2007, Philippe M. Chiasson <[EMAIL PROTECTED]> wrote: > The conceptual problem with this approach is that the digest(password) > effectively becomes the user's password. > > If you steal digest(password), you can impersonnate the user, without > ever knowing password. So, somebody stealing a dump of your user database > can still impersonnate all your users. > Then a malicious attacker that stole a bunch of digest(password) can > pre-calculate a single 'challenge' and pre-generate a single > challenge/digest(digest(password) . challenge)) > pair per account he/she stole. Then can use them to login straight at the 3 > step > of the authentication process with very little work on his/her side. Something doesn't sound right with this assessment. Stealing the digest(password) wouldn't let you in on a different connection because you'd be using a different seed on a different connection... To me it sounds like he's saying this: Server: Hi, there! Client: Hi, I'm a user Server: Okay, who are you and what would your password be if encrypted off of 1234567? Client: My username is 'foo' and my password, encrypted like you said, would be '[EMAIL PROTECTED](F HBUO' (Secretly, this is stolen by a packet sniiffer) (Server looks up foo's password and encrypts it off of 0987654 and gets '[EMAIL PROTECTED](F HBUO') Server: You're right! Welcome in! Server: Hi There! Hacker: Hi, I'm a user Server: Okay, who are you and what would your password be if encrypted off of 0987654? Hacker: My username is 'foo' and my password, encrypted like you said, would be '[EMAIL PROTECTED](F HBUO' (Server looks up foo's password and encrypts it off of 0987654 and gets '[EMAIL PROTECTED]') Server: Nope, foo's password, encrypted the way I said, does not come out to '[EMAIL PROTECTED](F HBUO.' Bugger off, wannabe leet hacksore. -- Dodger
Re: how to use Apache::DBI
Clinton Gormley wrote: On Mon, 2007-07-30 at 18:21 +0800, Ken Perl wrote: I've configured the Apache::DBI in httpd.conf like this, PerlModule Apache::DBI I didn't have Apache::DBI->connect_on_init($data_source, $username, $auth, \%attr) in startup.pl since we don't use startup.pl. and the doc says to config it in httpd.conf is OK. my question is I can not find any persistent connections for my CGI script. any usage error here? Persistent connections will not work for straight CGI scripts, because CGI is not persistent. For each CGI request, a new perl interpreter is loaded, your script is compiled, run, and the Perl process exits. mod_perl IS persistent, as are your CGI scripts run via ModPerl::Registry etc. You don't need connect_on_init to work, but you do need mod_perl Clint Mr Gormley, You're being semantically picky with this guy, and innacurately so. An apache registry script *is* a CGI script. So is an ASP page, a PHP script, and any other interpreted way fo dealing with CGI input. CGI stands for 'Common Gateway Interface and describes the method of transferring information to a form to the server. A CGI script is therefore a script designed to deal with CGI input, which means it doesn't matter if it's in Perl or not, and it doesn't matter if it's an Apache Registry script or a standalone non-mod_perl Perl script that's doing the work. All that matters is that it can read CGI input (or at least the subset that it's designed to deal with) and that it is interpreted at runtime (as mod_perl registry CGI scripts are). The guy also obviously most likely has mod_perl because he is using the PerlModule directive in his conf *and* because he's using a startup.pl file. -- Dodger
Re: TIPool
Not wanting to nitpick, but I'm going to a bit anyway... When people post to this newsgroup can they please try and come up with subject lines that are a bit more detailed and don't just seem on first glance to be randomly generated single words? Normally, I see a single word with an attachment in my email and... well... guess where it goes before I even look... -- Dodger
Re: Both mod_perl 1 and 2 on same machine
Modify @INC to only load the libraries you need, and make sure to install the MP1 modules in a different location than the MP2 ones. Basically, install the 'default' server perl modules normally, and install the 'other' ones in a special directory that you then modify @INC to include through use lib () or direct manipulation of @INC in a begin block. -- Dodger Walt Reed wrote: The apache part isn't the problem. I can easily run on different ports, and whatnot. In fact, both apache's are working fine independantly, so it's just the perl / mod_perl issue. When I do a "make install" of mod_perl 2.x I don't want mod_perl 2 based perl modules tromping all over the existing mod_perl 1.3 system install. Both my apache 1.3 and 2.2 installs are custom compiled into apache standard /usr/local/apache / /usr/local/apache2 trees (instead of using the hatchet job versions that redhat likes to ship.) The deal here is that the customer is migrating from an apache 1.3 setup to an apache 2.2 setup and only has one machine available in the colo. Adding another is not feasable at the moment. On Tue, May 15, 2007 at 03:47:19PM -0400, John Saylor said: hi ouch. the only suggestion i have is to reasess your needs. really- you'll spend at least 10 hours dicking around with the network config to say nothing about httpd.conf. if you get paid over $10. and hour, that makes it worth it buy a new machine. -Original Message- From: Walt Reed [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 15, 2007 3:39 PM [deletions] I have a need to install both apache 1.3.x / mod_perl 1.x and apache 2.2.x / mod_perl 2.x on the same machine.
Re: Odd problem
The Doctor wrote: I am runnng Apache 2.059 and perl 5.8.8 . I am trying to compile the most recent version of mod_perl 2 however once install, Apache says it cannot find the so even tough it is there. Pointers please. If the so is present, but not found, it may not be in the right directory. My usual solution is to simply link or symlink it to where it's needed to be.
Re: ENV
Jonathan Vanasco wrote:
Is there a way to get additional shell variables exported into ENV on
startup ?
// Jonathan Vanasco
Yup.
I do this:
package Local::PrepSession;
use DBI;
my $sql = DBI->connect('DBI:mysql:apache','**','**');
use Apache2::RequestRec();
use Apache2::RequestIO();
use Apache2::ServerRec();
use strict;
sub clearEnv();
sub killCookie($$);
use CGI::Cookie;
use Apache2::Const(':common');
sub handler {
my $r = shift;
my $s = $r->server;
my $sql = DBI->connect('DBI:mysql:apache','**','**');
my %cookies = fetch CGI::Cookie;
my $sessionid;
$sessionid = $cookies{'session'}->value if defined $cookies{'session'};
clearEnv;
$ENV{SESSION_ID} = $sessionid;
$ENV{SESSION_HANDLER} = 'PrepSession';
unless ($sessionid) {
# Session ID is undefined. No such cookie.
delete $ENV{SESSION_ID};
$ENV{NO_SESSION_REASON} = "No session cookie found";
$sql->disconnect;
return DECLINED;
}
my $sessionTables = {
'xfx3d.net' => 'xfx_session',
'gothic-classifieds.com' => 'gc_session',
'art-geeks.com' => 'ag_session',
'cryptbabes.com' => 'cb_session',
'moopleapproved.com' => 'mp_session',
'whatever3d.com' => 'whatever',
'mistressjadeor.com' => 'mj_session',
'club-nemesis.com' => 'nemesis_session',
};
my $dom = $s->server_hostname();
# debug
for my $envar (grep !/^ORIGINAL_/, keys %ENV) {
$ENV{"ORIGINAL_$envar"} = $ENV{$envar};
}
$ENV{DB_DOMAIN_ORIG} = $dom;
unless ($dom =~ /^[a-zA-Z0-9\-]+\.[a-zA-Z0-9\-]+$/) {
$ENV{DEBUG} = "Domain had to be stripped down";
if ($dom =~ s/.*\.([a-zA-Z0-9\-]+\.[a-zA-Z0-9\-]+)/$1/) {
$ENV{DOMAIN_CATCH} = "Did some stripping??";
}
else {
$ENV{DOMAIN_CATCH} = "Didn't match???";
}
}
$ENV{DB_DOMAIN} = $dom;
my $session_table = $sessionTables->{$dom};
$ENV{SQL_SESSION_TABLE} = $sessionTables->{$dom};
unless ($session_table) {
# request came in for a domain name without a session table
$ENV{SESSION_ID} = 0;
$ENV{NO_SESSION_REASON} = "No session table found for server $dom";
clearEnv;
killCookie($r, $dom);
$sql->disconnect;
return DECLINED;
}
$ENV{SQL_FULL_TABLE} = 'apache.'.$session_table;
my $get_session_st = <<"EOF";
SELECT *
FROM apache.$session_table
WHERE id = ?
EOF
my $get_session = $sql->prepare($get_session_st);
$ENV{GET_SESSION_PREPARED} = ref $get_session;
if ($sql->errstr) {
# we had an error preparing the session query
# don't kill the cookie -- it may be a temporary DB issue
$ENV{SESSION_ID} = '0E0';
$ENV{SQL_PREPARE_GET_SESSION_ERR} = $sql->errstr;
$sql->disconnect;
return DECLINED;
}
my $rows = $get_session->execute($sessionid);
if ($get_session->errstr) {
# We had an error executing the query
# don't kill the cookie -- it may be a temporary DB issue
clearEnv;
$ENV{SQL_EXECUTE_GET_SESSION_ERR} = $get_session->errstr;
$ENV{SQL_FAILED_STATEMENT} = $get_session_st;
open ERRLOG, ">>/usr/local/apache2/logs/session_errlog";
print ERRLOG "Get_session error: ", $get_session->errstr, "\n";
close ERRLOG;
$get_session->finish;
$sql->disconnect;
return DECLINED;
}
unless ($rows + 0) {
# the submitted Session ID cookie is invalid. No match.
killCookie($r, $dom);
clearEnv;
open ERRLOG, ">>/usr/local/apache2/logs/session_errlog";
print ERRLOG "Invalid session $sessionid\n";
close ERRLOG;
$ENV{NO_SESSION_REASON} = "Invalid session $sessionid\n";
$get_session->finish;
$sql->disconnect;
return DECLINED;
}
my $session = $get_session->fetchrow_hashref;
$get_session->finish;
if ($session) {
my $expiry = $session->{remember} eq 'Yes' ? '+1y' : '+1d';
my $pcookie = CGI::Cookie->new($r,
-name => 'session',
-value => $sessionid,
-expires => $expiry,
-path => '/',
-domain => ".$dom");
$r->headers_out->set('Set-Cookie' => $pcookie);
for my $svar (keys %{$session}) {
$ENV{uc("SESSION_$svar")} = $session->{$svar};
}
if ($session->{access}) {
my @access = split /;/, $session->{access};
for my $a (@access) {
my ($ap, $t) = split /:/, $a;
$ENV{uc("ACCESS_$ap")} = $t;
}
}
my $update_session_st = <<"EOF";
UPDATE apache.$session_table
SET last_action = NOW()
WHERE id = ?
EOF
my $update_session = $sql->prepare($update_session_st);
$update_session->execute($sessionid);
}
else {
clearEnv;
killCookie($r, $dom);
$ENV{NO_SESSION_REASON} = "Session id not found in $session_table";
}
$sql->disconnect;
return DECLINED;
}
sub killCookie($$) {
my $r = shift;
my $dom = shift;
my $mcookie = CGI::Cookie->new($r,
-name => 'session',
-value => '',
-expires => '-1d',
-path => '/',
-domain => ".$dom");
$r->headers_out->set('Set-Cookie' => $mcookie);
}
sub clearEnv() {
for my $envar (grep /^(SESSION|ACCESS)/, keys %ENV) {
delete $ENV{$envar};
}
}
1;
and in the httd.conf:
Options Indexes FollowSymLinks MultiViews Includes ExecCGI
AllowOverride All
Order allow,deny
Allow from all
PerlOptions +ParseHeaders +GlobalRequest +SetupEnv
PerlFixupHandler Local::PrepSession
This sets up certain things based on the session cookie, including
getting any parametre stored in the session table (which is a faster
lookup than, say my members table) and also their access levels (which
is w
Re: [JOB] Perl Programmer for large-scale Apache/mod_perl development
If you're unwilling to let a programmer telecommute, you're still in the dark ages, and I wouldn't want to work for you anyway. I am amazed by the technology companies that think that programming requires physical presence in the 21st century. Yeesh. -- Dodger On Mon, 6 Jun 2005, Sam Tregar wrote: > NEW YORK CITY AREA ONLY > > Plus Three is looking for an experienced Perl programmer to join our > team. You will join a large-scale, high-visibility project with the > potential to positively affect the future of the Democratic party > during the next election cycle. > > We're looking for someone who enjoys programming as much as we do and > is always interested in learning more. Our team conducts weekly code > reviews and is involved in the Perl community. > > Required skills: > > * Significant development experience in a professional environment. > > * Solid programming experience with Perl, including extensive use of > object-oriented features, code testing and CPAN modules. > > * Apache/mod_perl development experience > > * Working knowledge of SQL > > * Working knowledge of e-mail > > * Communication - ability to discuss requirements clearly with > non-technical users > > Desired skills: > > * Experience with our toolset: Class::DBI, CGI::Application, > HTML::Template, and Krang. > > * MySQL development experience > > * Linux programming experience > > * E-mail campaign experience > > * Open source development experience (CPAN authors preferred!) > > * Test-driven Developemnt > > * Advanced database tuning > > > Send resume and code samples to [EMAIL PROTECTED] >
Re: Autoflush without NPH...
- Original Message - From: "Perrin Harkins" <[EMAIL PROTECTED]> To: "Dodger" <[EMAIL PROTECTED]> Cc: "Modperl List" <[EMAIL PROTECTED]> Sent: Friday, April 16, 2004 10:52 AM Subject: Re: Autoflush without NPH... > On Fri, 2004-04-16 at 13:37, Dodger wrote: > > Now, as long as PerlSendHeader is*On* will that make sure that it does NOT > > run as an NPH script if $! is set to 1? > > Do you understand what an NPH script is? It simply means that the > server is not parsing your output and adding headers, the way it > normally does when running under mod_cgi. Technically, all mod_perl > handlers and any Apache::Registry script run with PerlSendHeader off is > equivalent to an NPH script. Yep, of course. I've written several. At least half I've written won't work on IE because it won't do replace boundaries correctly. One was a nifty web-based MUD client, without so much as a hint of java or anything like that. > Turning autoflush on is not really part of it, but since people usually > are turning off header parsing in order to output something that > updates, it is a common practice. Buffering would kill things like > server-push, which was the main thing NPH scripts were used for. > > - Perrin All I have to go on is the documentation, which is noticably sparse in this area -- and DID indicate that turning autoflush on is really part of it. I got the impression that Apache::Registry does stuff when dealing with the script before running it, and I thought that it might possibly be doing some magic behind the scenes if it located $| being turned on. Anyway, I just tried it and it didn't seemto pay any attention to the vaue of $|. Seemed to block buffer everything anyway. -- Dodger -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Autoflush without NPH...
Hi, all. Okay here's one I'm curious about... don't need it immediately, I think, but it would be nice to undesatand ahead of time. According to the mod_perl documentation, it says: - To run a Non Parsed Header CGI script under mod_perl, simply add to your code: local $| = 1; And if you normally set PerlSendHeader On, add this to your server's configuration file: PerlSendHeader Off - Now, as long as PerlSendHeader is*On* will that make sure that it does NOT run as an NPH script if $! is set to 1? The reason is that I have been known to set $| to 1 when I've got a *regular* script doing thngs that might go slowly (such as, for instance but not vital at the moment, on a 'Join' page printing out some reassurance to the user that things are being processed while connecting to the SMTP server to send the validation mail, which can be slow). I've even had some comments that it looks really neat when I do this, since a newline doesn't mean a newline in HTML so I can do things like: Doing something that's slow: Done Doing something even slower: . . . Done (Even if the HTML source output ends up ugly) (The 'Done' parts and the dots appear after things are done or stages of the things are done, and show up on the browser as they are complete, as the page simply hasn't finished loading, but it looks all dynamically interactive when it's really not, plus there's no 'wait time' where the user might be hitting refresh and stupid things like that). However, if the PerlSendHeader On doesn't stop it completely from being an NPH script, then doing this would theoretically cause problems, I'd think. Any elucidation out there? -- Dodger -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Semi-newbie question.
Hi, all.
I'm sort of a mod-perl newbie.
That is to say, I've used mod-perl plenty of times just as a way of speeding
up CGIs using Apache::Registry, but I haven't hacked into the server with it
yet.
At this point, however, I'm diving in.
What I want to do is to set things up so that any .mp or .php file has a
subroutine run first, to do my own home-rolled session stuff (I don't much
like Apache::Session's say of doing it, sorry to the creators of it).
In the past, of course, I'd simply require the session in the .mp file (I
make mod_perl script .mp and mod_cgi scripts .cgi, so that I can link the
other extension to the same name and test under both configurations, as well
as developing under the .cgi extension because I roll a lot of my own
modules and don't like having to restart Apache to recompile the modules I
write).
However, as the site I'm building now uses both PHP *and* Perl CGIs (under
mod_perl in production), I want to do the session stuff outside rather than
writing a PHP module to duplicate the Perl functionality or something.
I figured the easiest thing to do would be to get the cookie, connect to the
database, retrieve the sssion stuff, and then set environment variables
based on the results, i.e., if the cookie is present, look up the session
data in the session table, and set an environment variable for each session
variable retrieved form the database (in simple form). Also to delete the
cookie (reset it with an expiry of yesterday) if it's invalid (not matching
an id in the session table, that is). Thereby all the sesion info is simple
stored in environment variables.
Now, looking at mod_perl, it *seems* this should be easy to implement.
Except I can't figure out how to do it.
PerlHandler doesn't seem to be what I want, because it will then not
actually run the Perl or PHP script.
Perl*Handlers are probably it somehow, except the documentation at
http://perl.apache.org/docs/1.0/guide/config.html#Perl_Handlers doesn't
actually seem to bother saying WHAT all those Perl*Handlers are for (and if
someone out there thinks that the names make them self-explanatory --
well -- that may be true to a C coder who deals with writing Apache modules
all the time, but not for me.)
blocks aren't it either from what I can tell. I tried something as
simple as setting $ENV{TEST_THINGY} = `date`; in a block and it works
fine when the server starts up, but it doesn't do it afterwards. It's always
got that same date which shows me that blocks aren't interpreted
except that first time.
-
Another thing I've found odd --
when I set environment variables from a block with $ENV{WHATEVER} =
'some value' -- it works fine as long as I PassEnv it after. When I set them
with SetEnv, it works fine. But when I set them with PerlSetEnv it's
weird... it works fine in mod_perl, doesn't work under mod_cgi, and works
under mod_php ONLY after a .mp script has been hit. I don't really get why
this is.
-
Anyway -- so yeah -- I wanted to do something that should be really
simple -- check the database based on a cookie, if present, and delete the
cookie if it's invalid, otherwise set several environment variables so that
PHP and Perl knew the same things from the session, and then run whatever
script was requested -- but it's turning out to be a headache and I'm having
a LOT of trouble figuring out what order the documentation is supposed to be
read in (not to mention continually annoyed that everyone who writes such
documents doesn't seem to understand that some people -- like me -- HATE the
concept of ScriptAliases, and so seeing everything written as if this is the
way it's normally done is a bit irritating).
--
Dodger
P.S. As a note: I can't afford to buy a book right now. I'm in Portland and
the dot-com-crash is not over here. I'm getting booted from my apartment
because I don't have the exorbitant suburban rent, and I live on Ramen.
Please don't tell me to go buy the Eagle Book. The answers I seek should be
somewhere other than a book.
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
