SitePoint Sponsor

User Tag List

Results 1 to 11 of 11
  1. #1
    SitePoint Member
    Join Date
    Feb 2008
    Posts
    9
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    trouble using session_id($sid)

    I'm working on a photo upload setup that uses a flash movie (swfupload) to upload the photos. There's a bug (or feature?) in flash that keeps it from passing cookies with the form post, so I'm developing a workaround for session persistence. People who aren't authenticated users can't upload photos, but I can't recognize them w/o sessions!

    When I pass the sessionID as a post variable, I should be able to retrieve the previous session like this:

    Code:
    //get $sid from $_POST
    session_id($sid);
    session_start();
    When I call session_id() after session_start(), it returns the correct value (equal to $sid), but $_SESSION is empty! What would cause this?

    Some sticky details:
    When I use the very simple setup shown above, it DOES work, but the architecture of my site is more complicated than that. When I integrate the basic idea into my site, it doesn't work. What kinds of things would interfere with this?

    Here are the things I've checked:
    I have suhosin installed, but the problem persists when I put it in simulation mode.
    I have checked that the session ids are of the same length, so no spaces are being added in the form post.
    I have checked that the $_SESSION array is not empty on the previous page, from which the value for $sid is passed.

    If anybody has any insight, obvious things I might've overlooked, or similar experiences, I'd love to hear what you have to say.

    Thanks,

    grossvogel


    PS - I'm aware that passing sessionIDs around like this is flaunting some security best practices, but I'm also using single-use session tokens, logging, and a temporary file holding bin (not web accessible) to reduce the risks. And yes, I've checked that the $_SESSION array is empty BEFORE my session token code has a chance to wipe it out.

  2. #2
    SitePoint Zealot
    Join Date
    Jun 2008
    Posts
    192
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    use it
    Code:
    session_start();
    session_id($sid);
    use session_start() function 1st first after <?php

  3. #3
    SitePoint Member
    Join Date
    Feb 2008
    Posts
    9
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I've seen lots of posts where people say 'you have to use session_start() in the first line of your script', but I know it to be false.

    Yet, there's a reason people say this. Mysterious problems go away when you remove everything else. (In my original post, I stated that it works for me when it's the only thing happening in the script...)

    What I want to know is, if you don't put session_start() right at the beginning of the script, what kinds of things cause it to behave strangely? I'd expect that setting headers or cookies might interfere, but I'm not doing any of those things...

    I am intrigued by the ordering of your session_start() and session_id() calls. I'd not tried it that way because the manual says it should be the other way around:
    If id is specified, it will replace the current session id. session_id() needs to be called before session_start() for that purpose.
    still, i get slightly better results your way (half the values from my $_SESSION array are there now?!?)

    Can anybody explain what's going on?

  4. #4
    play of mind Ernie1's Avatar
    Join Date
    Sep 2005
    Posts
    1,252
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    session_id() is used to get or set the session id for the current session.
    If id is specified, it will replace the current session id. session_id() needs to be called before session_start() for that purpose.

    Now, I think you don't want this.

    You can call/assign the session_id like this:
    PHP Code:
    echo session_id();
    $sid session_id(); 
    Note:
    When using session cookies, specifying an id for session_id() will always send a new cookie when session_start() is called, regardless if the current session id is identical to the one being set.
    my mobile portal
    ghiris.ro

  5. #5
    SitePoint Member
    Join Date
    Feb 2008
    Posts
    9
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Ernie,
    Thanks for replying, but I DO want to set the session_id. My app works fine using cookies to store session info, but I have one script that processes photo uploads from a flash movie.

    The flash movie cannot send the cookie, so i'm passing the id in a post field. my issue is, when I get the id from $_POST and assign it using session_id($sid_from_post), i end up with an empty $_SESSION array, when I know there should be data in it.

  6. #6
    play of mind Ernie1's Avatar
    Join Date
    Sep 2005
    Posts
    1,252
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    maybe the $_SESSION array is empty because no value is set

    try to echo the session_id() on the next page but without assigning a new id to the session_id() and after starting the session with session_start()
    see what is happening
    my mobile portal
    ghiris.ro

  7. #7
    SitePoint Member
    Join Date
    Feb 2008
    Posts
    9
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    since the flash plugin doesn't send a cookie, the call to session_start() will generate a brand new session id, unless I tell it which session id to use. And $_SESSION is going to be empty in that case, for sure.

    I know there is data in $_SESSION on the referer page because I'm spitting it out with print_r just to be sure.

  8. #8
    SitePoint Wizard bronze trophy
    Join Date
    Jul 2008
    Posts
    5,757
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    How long(seconds, miliseconds) would you say between the point where php initially outputs the html for the flash file, until the time where the browser sends the new http request from flash? For example, if flash sends the request immediately upon loading, you may have a race condition which will cause exactly this behavior, espescially if the script outputting the html takes a long time to finish execution after the point of outputting that chunk of html. We can solve this a few ways. I will explain more if this seems probable.

    I want you to run this in the script which receives the http request from flash.
    PHP Code:
    // this should produce the correct path/filename. If it doesnt, modify as neccesary for your system.
    $sess_file session_save_path() . '/sess_' $sid;

    $contents file_get_contents($sess_file);
    session_id($sid);
    session_start();
    $serialized serialize($_SESSION);
    $dumped print_r($_SESSIONtrue);
    $str "
    file 
    $sess_file
    -------
    contents 
    $contents
    -------
    serialied 
    $serialized
    -------
    dumped 
    $dumped
    -------


    "
    ;

    file_put_contents('log.txt'$strFILE_APPEND); 
    That will alow you to see if the variables have been saved to the session file properly($contents), as the issue may be with session_start() loading them. Do the variables and thier values all match in all 3 dump strings? Describe the results.

  9. #9
    SitePoint Member
    Join Date
    Feb 2008
    Posts
    9
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Thanks for looking into this, crmalibu. I've got the results of your script, and it looks like there is nothing in the session file when the script catches the POST:
    file /var/lib/php5/sess_d04c82d6234b748189421ab5a473fbbf
    -------
    contents
    -------
    serialied a:0:{}
    -------
    dumped Array
    (
    )
    But the POST doesn't launch when the page is loaded. It waits for me to select a photo and uploads it along with the form data. So I don't see how this could be a race condition.

    I've also done some more diagnostics that might help, if you're still with me:

    When I read the session file in a terminal, I do see that the session data is in the file between loading the page and sending the POST, but it gets wiped-out by the calls to session_id($sid) and session_start() in the processing script. (I tried removing those lines, and the session file keeps its data.)

    I've also tried passing the $sid value from an established firefox session into a page in an IE window via $_GET, and the same thing happens. For some reason, calling session_id($sid) then session_start() wipes out the session data, even though it allows you to use the $sid you specify.

    (This means that, contrary to my previous statement, even the slimmed-down code doesn't work in my setup. I was foolishly testing with the same browser before, so the session cookie was sent.)

    Could this be a configuration issue? Does session.use_only_cookies prevent changing the session id to a value that doesn't match the cookie? Or some kind of referer check, maybe?

    Thanks again for all your help, everybody!

  10. #10
    SitePoint Wizard bronze trophy
    Join Date
    Jul 2008
    Posts
    5,757
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by grossvogel View Post

    When I read the session file in a terminal, I do see that the session data is in the file between loading the page and sending the POST, but it gets wiped-out by the calls to session_id($sid) and session_start() in the processing script. (I tried removing those lines, and the session file keeps its data.)
    This doesn't make sense.
    In my code snippit, we read the contents of the session file into a string before calling session_id() or session_start().

    This makes me think the session id your passing through POST from flash is not the id that contains the data.

  11. #11
    SitePoint Member
    Join Date
    Feb 2008
    Posts
    9
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    crmalibu,
    Thanks for all of your help. Now's the time that I confess that this was a wild goose chase.

    I retraced my steps to find that the suhosin plugin WAS to blame. I disabled the setting suhosin.session.encrypt in my php.ini, and it works fine now.

    I'm not too thrilled about having that thing disabled on my entire site (can't be overridden by ini_set), but at least I know what was going on.

    Thanks again.

    grossvogel


Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •