I have an ecommerce shop online using php, sql, javascript,ajax and sessions.
I have both guest and members cart options at checkout.
Everything works fine.
I store my cart items in a session currently.
Users can log in or have a guest cart.
Guests cart userids are referenced by the current session id.
members can login and their carts are referenced by their usersids from the database.
The problem is, the session expires after a certain amount of time and so the cart items are lost and the user has to start again.
On doing some research I have found that after the user logs in, I can store his user id in a cookie and I can specify how long that cookie lasts for which is ideal!
I am thinking of changing the code so that I store the items added to the cart in my database tables and simply reference them with the user id ive stored in his cookie.
That way He can shop for ages and not lose his cart and I can send abandon cart emails etc…
I think this would work well as nearly every website uses cookies so people have to have them enabled in their browser these days. I could show a warning message if cookies arent enabled anyway…
What does everyone think about this?
Please note I am not seeking security advice here.
Session ID also saved in cookie. So there is no real difference between both methods. Another question: do you really want persistent authentication ID on client side? Yes, I know…
Please note I am not seeking security advice here.
session.cookie_lifetime 0 (until browser is closed, else a non-zero value is seconds)
session.cache_expire 180 (3 hours)
Unless you see or know of any configuration values that might be responsible for a visitor losing their SESSION cookie, my guess is that they are not losing the SESSION cookie because of “a certain amount of time” but because SESSIONs must be passed page to page in unbroken sequence and there is a file somewhere that isn’t passing SESSION along.
Fair enough. Please note that I am not offering any solutions to the problem that are not secure.
Your members must sign in, correct? So you know their userid. If you use your database in your server then the members can use another browser or a totally different computer.
For guests one possibility is localStorage of the Web Storage API. That will limit the customer to just one computer and just one browser but you do not need a userid; it seems to me that you do not have a userid for guests. I cannot find it now but I think that if the user is using Chrome and if they are logged into a Google account then the localStorage can be synchronized with the Google account and therefore accessible from multiple systems using the same Google account.
Well, fair enough, but that’s… one of the two primary differences between PHP sessions and general cookies.
1 is their lifespans;
2 is what they can/should hold.
A Cookie lasts for a flexible length of time, but usually longer than a session, and persists between sessions within the confines of it’s lifespan. It’s stored on the client end of the communication, and is sent back and forth with every request, so it should not contain information the server wishes to remain secure, either in the case of someone observing the cookie, or in the case of the user manipulating the cookie.
A PHP session lasts for a length of time defined by the server (usually 15 minutes past the last interaction). All of the session information (excepting the SessionID, which is usually stored in a cookie for the client to identify itself) remains inside the server, and cannot be accessed by the user or any man-in-the-middle sniffing the communications. Sessions are the place to store important things like whether or not this user has access to administrator functions of your website.
As far as storing a UserID, i’d suggest it be stored as a session variable; otherwise when i go to check out, I could tell your server i’m you, and charge thousands and thousands of dollars to your account.