I read many recommendations to use the session id as the key to a directory or database key for saving sensitive info such as the user id.
But (as an old mainframe CICS programmer), I worry that the session-id will change between the time I send (echo) a form and the time I pick up his/her “submit”.
Don’t know that I’m making sense. Let’s try this. Suppose I create a form (in, say, view-class “domainfolder/formtosend.php”).
Before I “echo”, I acquire and use the session-id as a database key to store the userid. I then “echo” the form.
The user fills in the form and submits it. (with, say, form action=“domainfolder/index.php?task=whatever”…).
Will the session id that I’d acquire in domainfolder/index.php (upon the user “submit”) be the same as the session id I saved when I “echo”-ed from “domainfolder/formtosend.php”?
And, suppose it is a multi-screen form where what the next form displays (via PHP code) depends on the content of the previous form.
enuf already. As I said, this is no doubt a silly question.
A session key usually doesn’t change. The exception being if you call [fphp]session_regenerate_id[/fphp], and I’m fairly certain there are some PHP extensions that toy around with the session ID (although I can’t remember which ones; it wouldn’t surprise me if suhosin was among them though).
Anyway, PHP generates a session id for a user when you call the [fphp]session_start[/fphp] function. It then sends a cookie with that session id to the user (or it puts in the URL, but this is not very common, and very prone to session hijacking).
After the user has received the cookie with the session id, they will submit this cookie to the website with every request they make to that particular website, upon which PHP can read the session id and restore the session it created for the user back in memory.
When the user closes his browser, the cookie is removed from his system and the session no longer exists (of course at this point the info stored on the server for the session still exists, but this will eventually be cleaned by PHP’s garbage collector).
As for the recommendations to use the session id to store user info in the database or file system, that’s partially true. You can indeed let PHP store the session info in the file system (default) or database, or even go fancy and use something like memcache.
But everything regarding sessions is volatile and should be seen as such. It’s just PHPs mechanism of being able to remember information about a visitor spanning several server hits.
What I’m trying to say is that session ids are temporary and your main data should never rely on them.
Also worth pointing out that the session does have a timeout as well; if your user goes off to dinner before pushing that submit button, their sessionID can change when a fresh session is started when they hit your server again.
So what I take from this is that, in lieu of memcache,
I need to setup my session_start as a singleton pattern? Or only in my “signin” process?
And
that timeouts would leave orphans in my database?
You need to call session_start on every page you want to use session. What that function does is check the cookie the user sent, and find the related info in the storage space the sessions live in.
And timeouts do not leave orphans in your database, because PHP cleans out the data of timeouts (which is why they time out in the first place; there is a cookie but no info on the server, so we could actually say the cookie is orphaned :))