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