Jump to content

Saving session information after browser closed


azunoman

Recommended Posts

I use $_SESSION globals extensively.  They work great until the user closes the browser.  When they come back to our site their information, i.e. cart etc are long gone. 

 

I would like to generate a cookie that would be used to the session ID where I can then store $_SESSION (serialize) for subsequent retrieval. 

 

Can someone point me to an good tutorial?  function or class....Thanks in advance for helping this old broke down 360 assembler programmer.  :)

Link to comment
Share on other sites

I use $_SESSION globals extensively.  They work great until the user closes the browser.  When they come back to our site their information, i.e. cart etc are long gone. 

 

I would like to generate a cookie that would be used to the session ID where I can then store $_SESSION (serialize) for subsequent retrieval. 

 

Can someone point me to an good tutorial?  function or class....Thanks in advance for helping this old broke down 360 assembler programmer.  :)

 

I think you would be better off putting that info the DB instead of in a cookie. Either serialize the session array and put it in a DB column or make a column for each possible item in the array. I would make the DB field a text type and have the primary key be the userid, then on re-login check if they have a session in progress, if they do re-instantiate that session.

 

EDIT:

To do this you would want to update the DB each time the page is reloaded, so you have the most up to date session data stored.

Link to comment
Share on other sites

The session id is stored in a cookie that is destroyed when the browser closes.

 

You should be able to either edit the cookie expiration to some time in the future so as to make it remain after the browser closes, or just gather the session ID and post it in a new cookie.  When the user returns read their cookie, and reset session name and id accordingly before starting the session.

 

The rest of your session data can be stored in a database with PHPSESSID as the index.

 

Don't forget though, if there is any sensitive data to require some form of validation so someone else can't edit their cookie to a random session id and highjack someone's data.

Link to comment
Share on other sites

"I think you would be better off putting that info the DB instead of in a cookie."

 

I agree.  I currently serialize session data and file it in a DB when someone adds something to a cart, as an example.

 

"The rest of your session data can be stored in a database with PHPSESSID as the index."

 

I would like to do this...again I already serialize info and store in a blob for later look see.

 

Do I store the session ID on their machine by cookie so that when they return some time in < expiry time retrieve the session_id from the cookie then retrieve and unserialize $_SESSION into itself?

 

 

Link to comment
Share on other sites

 

 

For a shopping cart where you expect the data to not be lost if someone closes their browser, dog chews through their power cord, laptop battery dies..., you should be storing the cart items directly in the database instead of session.

 

You will find that this results in the simplest code and for things like inventory management when someone does not complete an order, your cron job that updates the available quantity only needs to scan the pending orders past a certain date in the database, because all the necessary information will already be in the database instead of in leftover and possibly lost (due to garbage collection running) session data files.

Link to comment
Share on other sites

 

 

For a shopping cart where you expect the data to not be lost if someone closes their browser, dog chews through their power cord, laptop battery dies..., you should be storing the cart items directly in the database instead of session.

 

You will find that this results in the simplest code and for things like inventory management when someone does not complete an order, your cron job that updates the available quantity only needs to scan the pending orders past a certain date in the database, because all the necessary information will already be in the database instead of in leftover and possibly lost (due to garbage collection running) session data files.

 

Dont forget that some users, everytime their browser closes they wipe out their cookies (I do that all the time). Storing it in DB on each load is the best way to go imo. Then when that user logs in restore their shopping cart. If the user is not registered, well they should have registered.

Link to comment
Share on other sites

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.