Perl to use and create PHP sessions?

[Wanna-Be Sys Admin]

Hi,

I'm as familiar with PHP as I am with Perl (which I've been using for a
decade), and I prefer to code in Perl over PHP in every instance. The
problem is other developers at my job code in PHP and want my code to
work with their PHP scripts for a few things where variables can't just
be passed back and forth (regarding sessions).

To put it plainly, it's a centralized login, and once someone logs into
the main area (PHP driven), they should be able to use my contributed
scripts without logging in again by just following a link normally, and
then go back to a PHP driven area once they are done (if they choose
to). Ideally, if they hit my scripts first and log in there, they
should be able to not have to log into the PHP area either.

I've rolled out my own custom sessions for the Perl scripts, and it's
doing everything it should, but I need to tie into the main company
area scripts seamlessly, really, only for this particular task of
logging in (from my scripts or theirs) and using all areas (PHP or Perl
driven).

I've looked at the PHP::Session module, but it only mentions working
with PHP 4 sessions (not PHP 5). Perl is running in CGI with the
SuEXEC wrapper and PHP is currently running as DOS (mod_perl). Does
anyone have any advice or experience with this? I have to figure out
how to have this user Perl will run as read the global user file (owned
by nobody) as a first hurdle (since it's only set to the nobody user
with permissions of 600).

Secondly, is reading/writing and using the sessions from Perl, but I
don't want the session to be created with world read/write, but I don't
know how else their PHP scripts can use the session or remove it when
needed.

In the end, I can force people to just log in with the same credentials
for my area, but I'd like to be company friendly with the other
developers and not have to recode this in PHP, if I can help it (though
it's not the end of the world if I do have to). Any ideas, suggestions
or experience by anyone of how to get around this would be greatly
appreciated. Thanks.

 

[Wanna-Be Sys Admin]

geez, major typos here:

I'm as familiar with PHP as I am with Perl

I'm NOT as familiar with PHP as I am with Perl

....

with PHP 4 sessions (not PHP 5).  Perl is running in CGI with the
SuEXEC wrapper and PHP is currently running as DOS (mod_perl).

Should say PHP is currently running as a DSO (Apahe module) for mod_php
(NOT mod_perl -- that would make the problem easier to deal with them,
ironically. Perl is CGI/SuEXEC, PHP is mod_php, to be clear).

Anyway, please let me know if this seems possible (and remember, I can't
change how Perl runs as CGU w/ SuEXEC or change any of their PHP
scripts).

 

[Wanna-Be Sys Admin]

Anyway, please let me know if this seems possible (and remember, I
can't change how Perl runs as CGU w/ SuEXEC or change any of their

^^^

CGI, not CGU. Also, above, was Apache (but that was likely obvious).
Man, I'm just going to stop typing for a while today!

 

[Wanna-Be Sys Admin]

Ben Morrow wrote:
....

One rather crude approach would be to write a minimal PHP script that
just dumps all the session variables (as plain text, or JSON, or
something) and then invoke that script using LWP from your perl
scripts, passing along all the appropriate cookie headers. If you are
able to it would probably be a good idea to disallow access to that
URL from outside your site.

Any other approach is going to have to start by giving Perl some sort
of access to the php sessions file. Whether that means changing its
permissions, running perl as the appropriate user, or writing some
sort of daemon running as the right user that will read the file for
you is up to you. All have their upside and downsides, and all would
need careful consideration of any possible security implications.

Ben

Unfortunately, anything related to changing the existing PHP code the
other developers wrote, including asking them to open permissions, or
run PHP so it runs as the user as well, are all out of the question.
This is a company system, but I still don't want to open too great of
permissions for any sessions that will house anything related to the
login info, and no non staff should have access, but it's still
something I won't want sitting there (especially readable from any PHP
script running as the web server user). The sessions I've created only
store non sensitive information per user and connection, so I'm not
concerned about that portion, but if PHP needs those credentials, then
all bets are off anyway. I am thinking that I'll just have to tell
them to "use the same login credentials" if they want/need to access
the area of the web interface I'm creating, because nothing else is a
problem and it needn't impose any security concerns (whereas working
with existing PHP sessions probably will by the looks of it).

Perhaps, I can find some method to read the cookies to see if a session
file exists (such as in /tmp) and assume if the session exists and
their cookie has any session login credentials (which will match the
login checks anyway), that the session is valid and just create a new
one for my area, they'll be shot back to the PHP session if they go
back to that area. A little difficult to explain, but I think the
difference in ownership and permissions across the PHP user and CGI
user, just present too much of an issue, unless the PHP developers were
willing to pass a specific argument my script(s) could check to verify
and existing session. Besides, trying to work with one, and knowing
the session should still be valid, isn't something I'd want to only
rely upon and further checks would be required anyway. Maybe I'll just
break down and try and recode it in PHP, but I'll save that for later
if needed. Thanks for the input.

 

[ccc31807]

To put it plainly, it's a centralized login, and once someone logs into
the main area (PHP driven), they should be able to use my contributed
scripts without logging in again by just following a link normally, and
then go back to a PHP driven area once they are done (if they choose
to).  Ideally, if they hit my scripts first and log in there, they
should be able to not have to log into the PHP area either.

I'm not at all familiar with PHP, but have written a fair amount of
ColdFusion and JSP. My approach to sessions is to use a database for
the current sessions. Any script that can access the database can
authenticate the user and validate the session (or create the new
session).

In my web apps, sessions are application wide, database driven, and
don't depend on cookies. I've never had the problem you've described
(but then, I don't know anything about PHP.)

CC.

 

[Wanna-Be Sys Admin]

I'm not at all familiar with PHP, but have written a fair amount of
ColdFusion and JSP. My approach to sessions is to use a database for
the current sessions. Any script that can access the database can
authenticate the user and validate the session (or create the new
session).

In my web apps, sessions are application wide, database driven, and
don't depend on cookies. I've never had the problem you've described
(but then, I don't know anything about PHP.)

CC.

I'm not a big fan of PHP, I've known Perl for a long time, and PHP
wasn't popular when I was coding in Perl, so I never got into learning
yet another laguage too in depth. However, it's okay and I don't mind
it that much, I just have to reference a lot to find the same functions
in PHP as Perl, but they are similar enough where I can get into it
enough, though they might want some more involved things if I do that.
Anyway, I just can't change how it works now. They both do share the
same database, but I don't see any data stored that I could access to
verify if a session for the login is stored in the database from my
script.

I can cross reference the same login data to check against, but that's
about it, the rest use PHP sessions and Smarty, and it just makes it a
serious hassle. So, I'll just stick with having people log in/out of
my area separate, at least for the time being. It seems dumb to recode
it all in PHP just to have it in PHP, and I get the annoyance of
logging into two separate areas, even with the same credentials, but my
area is more specialized and it works without a problem and will for
years to come, so I hope they realize that and don't sweat this small
issue (I was just trying to be friendly, I don't mind trying, but in
this case it's too much of a hassle).