AmigaKit down?

[LoadWB]

motorollin wrote:

The session ID can be stored in a cookie and passed to the web server, or passed between pages by storing it in $_SESSION. Either of these would be preferable to passing the session ID in the URL.

The PHPSESSION value stored in a Cookie or POST identifies the session to a new page in order to populate the $_SESSION super-global.  So you can't store the session ID in a $_SESSION variable and expect it to work.  A cookie is preferable to POST as the POST would require a hidden variable in a form rendered in plain-text html, and therefore subject to cache snooping after the fact.

Most of the time what happens is people are so overly paranoid about cookies that they don't allow them, period.  This breaks many sites' functionality.  Good, active anti-malware software and having third-party cookies disabled in the browser will generally keep users' machines clean (generally.)  Disabling cookies altogether is a bad thing, IMHO.

I'll accept any cookie, so long as it's chocolate chip or white chocolate chip without the nuts.  :crazy:

[LoadWB]

motorollin wrote:

LoadWB wrote:
The PHPSESSION value stored in a Cookie or POST identifies the session to a new page in order to populate the $_SESSION super-global.  So you can't store the session ID in a $_SESSION variable and expect it to work.

I'll have to take your word for that. I could never get sessions working properly using $_SESSION so I don't think I understood it properly. I ended up storing the user's variables in a database table and recovering them using the session ID stored in the cookie :-?

It's actually easier than it seems.  Before you send any output to the browser, issue a start_session() then you can begin populating $_SESSION variables.  On the next page, issue a start_session() again and you can use the variables.  When you're done, issue a session_destroy() and that's it.

In interim pages you can also issue a session_regenerate_id() to avoid session fixations.  This calculates a new session id and issues it to the browser.  Put "true" as the function parameter and it will also destroy the old session store (the file, mm entry, sqlite row, etc.) while transferring the $_SESSION variables to under the new ID.

[LoadWB]

motorollin wrote:

So how does the web server know which session to issue to the browser on subsequent calls to start_session()? Is there a predefined variable which you set to the session ID for start_session() to pass back?

Using LiveHeaders, I see that every connection to the server the browser sends a Cookie: header with the PHPSESSION value.  The server can then react upon it if the session is still valid.  The start_session() doesn't necessarily instantiate a session, it enables your page to use a session.

What I just noticed, and I'm not quite sure where to point the finger on this one, is that between my Firefox 3 and PHP5, an old session ID is being reused.  This probably has to do with cookie expiration (default is 0, which is to expire when the browser closes, which I generally hardly ever close) and me not generating new session IDs... which I will definitely start doing.

I did find a note in PHP's bug system from 2001 which illustrated that a client can specify the session ID when instantiating a new session.  In the end, it was decided that this is not a bug.