Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Perl > Perl Misc > Perl to use and create PHP sessions?

Reply
Thread Tools

Perl to use and create PHP sessions?

 
 
Wanna-Be Sys Admin
Guest
Posts: n/a
 
      11-19-2009
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.
--
Not really a wanna-be, but I don't know everything.
 
Reply With Quote
 
 
 
 
Wanna-Be Sys Admin
Guest
Posts: n/a
 
      11-19-2009
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).
--
Not really a wanna-be, but I don't know everything.
 
Reply With Quote
 
 
 
 
Wanna-Be Sys Admin
Guest
Posts: n/a
 
      11-19-2009
Wanna-Be Sys Admin wrote:

>
> 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!
--
Not really a wanna-be, but I don't know everything.
 
Reply With Quote
 
Wanna-Be Sys Admin
Guest
Posts: n/a
 
      11-19-2009
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.
--
Not really a wanna-be, but I don't know everything.
 
Reply With Quote
 
ccc31807
Guest
Posts: n/a
 
      11-19-2009
On Nov 18, 7:41*pm, Wanna-Be Sys Admin <(E-Mail Removed)> wrote:
> 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.
 
Reply With Quote
 
Wanna-Be Sys Admin
Guest
Posts: n/a
 
      11-20-2009
ccc31807 wrote:

> On Nov 18, 7:41┬*pm, Wanna-Be Sys Admin <(E-Mail Removed)> wrote:
>> 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.


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).
--
Not really a wanna-be, but I don't know everything.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: getting perl and php to talk to each other, was Re: randomlysorting files in php M. Strobel Perl Misc 1 03-05-2013 07:20 PM
PHP Training Institute In Delhi, Live Projects on PHP. Short TermPHP Courses, PHP Scripts, PHP Training with Live Projects. Rajive Narain Java 0 09-18-2009 10:47 AM
RE: php and python: how to unpickle using PHP? Ted Zeng Python 0 10-13-2006 12:11 AM
php and python: how to unpickle using PHP? Ted Zeng Python 4 10-03-2006 03:07 PM
PHP/Perl/Unix Virus: delete config.php files asap Ignoramus6539 Perl Misc 2 08-30-2006 08:22 PM



Advertisments