Perl to use and create PHP sessions?

Discussion in 'Perl Misc' started by Wanna-Be Sys Admin, Nov 19, 2009.

  1. 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.
    Wanna-Be Sys Admin, Nov 19, 2009
    #1
    1. Advertising

  2. 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.
    Wanna-Be Sys Admin, Nov 19, 2009
    #2
    1. Advertising

  3. 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.
    Wanna-Be Sys Admin, Nov 19, 2009
    #3
  4. 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.
    Wanna-Be Sys Admin, Nov 19, 2009
    #4
  5. Wanna-Be Sys Admin

    ccc31807 Guest

    On Nov 18, 7:41 pm, Wanna-Be Sys Admin <> 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.
    ccc31807, Nov 19, 2009
    #5
  6. ccc31807 wrote:

    > On Nov 18, 7:41 pm, Wanna-Be Sys Admin <> 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.
    Wanna-Be Sys Admin, Nov 20, 2009
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Ken Cox [Microsoft MVP]

    Re: Relationship between IIS Sessions and ASP.NET Sessions?

    Ken Cox [Microsoft MVP], Aug 8, 2003, in forum: ASP .Net
    Replies:
    1
    Views:
    5,348
    Luther Miller
    Aug 8, 2003
  2. Rajive Narain
    Replies:
    0
    Views:
    1,576
    Rajive Narain
    Sep 18, 2009
  3. scottymo
    Replies:
    3
    Views:
    682
    Dominick Baier
    Sep 30, 2006
  4. Ignoramus6539
    Replies:
    2
    Views:
    194
    Colin McKinnon
    Aug 30, 2006
  5. M. Strobel
    Replies:
    1
    Views:
    205
    The Natural Philosopher
    Mar 5, 2013
Loading...

Share This Page