Semi-newbie question.

[Dodger <se...@aquest.com>]

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.)

<Perl> blocks aren't it either from what I can tell. I tried something as
simple as setting $ENV{TEST_THINGY} = `date`; in a <Perl> 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 <Perl> blocks aren't interpreted
except that first time.

-------------

Another thing I've found odd --

when I set environment variables from a <Perl> 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

Re: Semi-newbie question.

[Geoffrey Young <ge...@modperlcookbook.org>]

for the record, it's best to keep this stuff on-list, that way everyone can
benefit :)


>>>doesn't work under mod_cgi,
>>
>>hmm, are you sure?  that's not right.
> 
> 
> My bad-- that was wiout the PassEnv set. WIth PassEnv it does go through.

:)

> 
>>>and works
>>>under mod_php ONLY after a .mp script has been hit. I don't really get
> 
> why
> 
>>>this is.
>>
>>I wouldn't expect mod_php to see arbitrary perl variables, so I'm quite
>>surprised it can see them at all.  hmm...
> 
> 
> It can see the environment with the PHP getenv() function. Which is the
> whole goal of doing this stuff. 

this one is my bad.  mod_perl populates the subprocess_env table, which both
 mod_cgi and mod_php take into consideration.  I was on crack, obviously :)

> It was the one specificlly set with
> PerlSetEnv that didn't work *until some mod_perl script had been hit. THat
> was just weird. (is just weird). But it simply means I'll use $ENV{WHATEVER}
> = "some value"; followed by PassEnv.

if you're using an older version of mod_perl 2.0 (1.99_12 or earlier, IIRC)
then this makes sense - it was a bug that was fixed with mod_perl 1.99_13.
if you're using mod_perl 1.0 then I have no idea - it's definitely not
right, so if you verify the behavior again I'll look into it.


>>you are, there are a few other books out there that should help clarify
>>things a bit for you:
>>
>>  http://perl.apache.org/docs/offsite/books.html
> 
> 
> Thanks, but as I noted in my postscript to the post, I can't afford a book.
> I have to worry about where my naxk packet of ramen is coming from (no to
> mention where I'm going to live in a week -- it's hard to code under a
> bridge without a laptop and wireless network card -- and the latter would
> mostly only work because I'm in Portland).

I didn't read your post-script, so I'm sorry to hear that.  however, most of
the books listed have free online content, so their websites are still good
places to visit.  ours, at least, has 10 chapters (for some definition of
chapter) available for free.

HTH and good luck.

--Geoff

-- 
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

Re: Semi-newbie question.

[Geoffrey Young <ge...@modperlcookbook.org>]

> 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.)

try taking a look at this

  http://www.modperlcookbook.org/chapters/part3.pdf

the request cycle and what you can do with it is more complex than that, but
it may help put things into perspective for you.

> 
> <Perl> blocks aren't it either from what I can tell. I tried something as
> simple as setting $ENV{TEST_THINGY} = `date`; in a <Perl> 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 <Perl> blocks aren't interpreted
> except that first time.

<Perl> sections are executed at configure time, not at request time.

> 
> -------------
> 
> Another thing I've found odd --
> 
> when I set environment variables from a <Perl> block with $ENV{WHATEVER} =
> 'some value' -- it works fine as long as I PassEnv it after.

yes, that's the proper behavior.

> When I set them
> with SetEnv, it works fine. 

yup.

> But when I set them with PerlSetEnv it's
> weird... it works fine in mod_perl,

as it should, provided you haven't set PerlSetupEnv Off.

> doesn't work under mod_cgi, 

hmm, are you sure?  that's not right.

> and works
> under mod_php ONLY after a .mp script has been hit. I don't really get why
> this is.

I wouldn't expect mod_php to see arbitrary perl variables, so I'm quite
surprised it can see them at all.  hmm...

> 
> -------------
> 
> 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).

besides the mod_perl cookbook, which (IMHO) is aimed at someone right where
you are, there are a few other books out there that should help clarify
things a bit for you:

  http://perl.apache.org/docs/offsite/books.html

in general, the only way I (as a non-php person) know of to share data
between mod_perl and mod_php is to use the notes table - $r->notes in
mod_perl and apache_notes in php (IIRC).

HTH

--Geoff



-- 
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