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.
I havent implemented this as yet - Im really looking to see if I can set my session lifetime to last a few hours/days instead.
I see your problem with Guest checkout and normal checkout after login.
You can go and use cookies rather than using sessions for this.
Cookie have setcookie() function with time() method.
You can set an Expiry time for that.
Go and use, it can help you
Related
I know, that I can use \Session::getId(). But it changes form time to time. Maybe I do not understand the sessions. As I know it starts when php runs and it is deleted when php code is finished. On the other hand I read that session id is stored in cookie and when a user open your site again, the session 'restores'. So why in my case the session id expires so quickly. How can I get the 'session id' that does not change at least for a month and that is used by shopping carts?
Update: The question becomes a little confusing because I do not want how call some things and do not know how these things work.
I want to know how I can identify a guest user and get its unique id for some period of time (longer than sessions usually exist). In the result I want to have function someFunction which could do the following:
$guestId = someFunction();
$dbRow = Model::findByGuestIdOrNew($guestId);
// now $dbRow contains all previosly save info about a guest user,
// of it does not exists, create new row by `$guestId`.
It seems to me that there is some unique id of session, which exists for time longer than session. This thought came to me when I've seen that in most cart packages cart items are saved directly to session. I really do not know how long these packages store cart items, but I think this time is even longer than a week. This period of time for lifetime of cart was defined by me while working with such shopping platforms: shopify and bigcommerce. I know they store cart item longer than a week. So I want to know how they identify a guest user before he creates an account. Also It will be a useful information to know how long most 'shopping cart' packages store cart items.
Laravel implements a custom way of handling sessions, but the logic is the same as the one described by the PHP Sessions Documentation. Here's an excerpt from that documentation that pretty much explains the logic behind it:
Sessions are a simple way to store data for individual users against a unique session ID. This can be used to persist state information between page requests. Session IDs are normally sent to the browser via session cookies and the ID is used to retrieve existing session data. The absence of an ID or session cookie lets PHP know to create a new session, and generate a new session ID.
So your understanding of how sessions use IDs is right, but there is a another component to sessions that defines how long they last. Sessions expire after a predefined period of time, which in the case of Laravel, can be set in the config/session.php file:
'lifetime' => 120,
The above default value means that the session will expire after 120 minutes of inactivity from the user. There is also the option to expire the session when the user closes the browser, thus forcing a new session to be generated when he opens the browser again, by setting:
'expire_on_close' => true,
You should read the Laravel Sessions Documentation for more insight into how Laravel handles sessions, and also read the comments from the config/session.php file which explain what each configuration option does and what values it can take.
The above explained how sessions work in PHP and Laravel, so in your case to make the session last for a whole month you could set the lifetime value to:
'lifetime' => 60*24*30 // 60 minutes x 24 hours x 30 days = 43200 minutes
But that seems like a really long time to keep a session, especially if the session also contains authentication info. If you want to persist the contents of a shopping cart I suggest you store them in the database and when the user logs in the next time just populate the session from the database.
For example the Cartalyst Cart library (which happens to have really nice Laravel integration) handles all the logic behind a shopping cart, while offering a nice sync method that allows you to add the cart items stored in the database to your current session. You could do the following to restore a cart from the database:
// Get the items from the database
$items = CartItem::where('user_id', Auth::id())->get();
// Sync the items with the session cart
Cart::sync($items);
The above assumes you have a cart_items table that has a CartItem model attached, and that you're using the Laravel Authentication to handle users sessions, but as you can see it leads to a very easy to implement solution.
Currently I'm working on a Magento module that allows customers to upload files against their order at the product page.
So what I thought was to have the files saved in a folder created with the session id as the folder name, until they submit their order. But then I ran in to an issue with this solution, which is, when a customer uploads a file as a guest and if they logged in after, or if they create a new account, the session ID get change, and no way of back tracking previous session data or id.
I looked at visitor ID and that doesn't work either. coz for a new customers/visitors don't have a visitor id, so thats out too.
Any suggestion?
You can track such instances with a cookie & the right expiry time. The following documentation helped me out a lot when working with cookies:
http://www.quirksmode.org/js/cookies.html
Visitor ID doesn't change after login. It changes after logout, which is perfectly normal. Also, all visitors have visitor ID, whether they new or not or logged in or not.
I want to make persistent shopping cart in a store powered by Opencart. In other words, If a user add products into shopping cart and user is not yet logined. But next time when customer visit site again within a week his products should be in his cart.
Products should be removed only when user explicitly removed products from cart or checkout or after one week.
I think this can be done by using cookies? help will be appreciated
There's a VERY EASY WAY to do this.
This modification works with OC 1.4.X.X and OC 1.5.X.X
Here's how it's done:
In the home directory, find system/library/session.php
You will find a line that reads:
session_set_cookie_params(0, '/');
For a 24-hour cookie, change the line to:
session_set_cookie_params(60*60*24, '/');
You're multiplying the number of seconds in a minute by the number of minutes in an hour by the number of hours in a day, that you want to set the cookie to.
This is not a true persistent cookie, but rather a very long session cookie, and as Jay Gilford has pointed out, there's no [easy] way to create persistent cookies with OpenCart, and if we figure out a way to do this we will let you all know. And because OpenCart treats this cookie as a session cookie, no matter how long the session, it will not automatically update the cookie with a new expiration date so long as the cookie has not yet expired.
A harmless side effect of the extend session cookie is that when you log in to the administrator page without previously having logged out, you'll be greeted with an "invalid token" message. It's because the (extended) session cookie "remembers" your last administrator log in. Just ignore this and log in. There's another drawback though, which is that if there's a product price change, and a user has already added that product to the basket, the user will have the former price stored in the 24-hour cookie.
The reason why OpenCart is built like this appears to be the privacy laws of the European Union, which prohibit persistent cookies unless a registered user has not logged out. Many e-commerce websites using Opencart in the United States and Canada are being needlessly burdened by a hardwired cookie policy that is causing them to lose customers who return to their websites, only to have to do their ordering all over again.
There is no mod that will do this in opencart. As mentioned in the comments section, your best option is to use cookies with a token or set the session expiry to last as long as 7 days (though this has it's drawbacks)
This is wrong:
session_set_cookie_params(60*60*24, '/');
It should be:
session_set_cookie_params(time() + 60*60*24, '/');
Anyway, this modifies the core file (system/library/session.php), so really not a perfect solution.
Please see the next comment for the solution.
I'm working on a e-commerce website in PHP and I would like to implement the following feature: if a user is not logged in, he can add products to the shopping cart and still have those products after login. Also, the feature must work the other way around: a user is logging in and then he adds products to the shopping cart.
I thought that a good way to do this is by using the session id, but after doing some test it turned out that this isn't the best way to do it.
Any ideeas?
Why is using the session not the best way to do it? I'd say it is.
You could have a separate, session-based "non-logged in" shopping cart structure, an exact copy of the normal cart. If the user is not logged in, the products are stored there.
When the user logs in, you merge the non-logged in cart's contents with whatever items the user may already have in their user-speficic cart.
That point is also the place to deal with any conflicts that may arise from the product selection (like, a selected product being present in the logged in user's cart already).
Using cookies as recommended by #Codemwnci to either store the products, or a cart ID is a good idea too, because it allows the user to come back later and still have their cart contents, which you may want.
The same principle of merging will apply here as well, with an additional check whether the products in the cookie really are valid ones (they could have been removed since the user made their selection, or the user could have altered the cookie).
You can use cookies. Just store a unique identifier in the cookie, that represents the shopping basket. Regardless of whether the user is logged in or out, the Cookie identifier will still be the same, therefore the data will be persisted.
session_start();
$_SESSION["cartitems"] = "1,2,3";
I am in the process of making a website that involves a shopping cart.
There are two major requirements:
The user experience guys want login/authentication to be the very last step in the entire work flow. The user gets to do all the shopping and is asked to login only at the time of checking out.
The shopping cart shouldn't expire(not even on browser close) unless the user (registered or not) does check-out.
In the above context, I have the following question with respect to maintaining the cart's state:
Should I go with file based or database sessions? Please keep in mind this would be for unregistered users. My apprehension is that I'll end up having lots of records in the database.
Another option seems to be to put the cart contents in an encrypted cookie, but then there's a size limitation on the cookie file.
What would you do in this case ? I would really appreciate your answers.
Tracking a user. Use a GUID
encoded into a cookie with an
nYear expiry.
Storing a Shopping Bag. You don't want to store the bag in the cookie, mainly due its possible size. This leaves the option of persiting it to a medium and retrieving it from the medium. Using anything except a database for this would be like going back in time, databases excel at storing and retrieving data.
Managing you Shopping Bag. Now, the
question of your schema, firstly, if
your going to be running queries
against the shopping bags in the
database (i.e. how many shopping
bags contain item x) you probably
want a traditional relational
schema. However this has overheads
in terms of inserting. updating,
selecting (and joining) and deleting
bag data (at some point you'll have
bags that will never be used again
but are taking up precious disk
space). With a busy site, this is a
fair few Traranactions Per Second,
but any database should be able to
cope. If you don't need to query
the shopping bags in the database,
then you can store it as XML. Just
serialize the bag and dump it into a
table, with the PK as the GUID as
stored in the users cookie. This
would be a lot faster than a
traditional schema, plus you could
always tear apart the XML in the
future if a requirment did come up
for a relational schema.
This is what we do (Xml Bag), and we have a million+ customer base.
I would go with database managed sessions over file managed sessions. Make sure you have a session timestamp so that you can eventually kill old sessions (if it's been 12 months, the shopper is possibly not coming back for the items originally in the cart).
Doing this with a database instead of files will make it easier to eventually expire the very-old information.
Note that the database session will only ever be valid as long as the cookie it's tied to on the user's computer. If the user comes back to the store from a different browser, they will not find their session. If two people are sharing the same computer, they will find each other's session. Hopefully no potentially embarrassing items will be in the cart...
Store in cookies the AnonymousSessionID, with which you associate a shopping cart in the database.
Then you'll have a scheduler task to erase anonymous sessions after some time (say, a day). This will keep your database clean of abandoned sessions.
If a user registers, you reassociate their shopping cart with their account permanently. If the users makes an order, you empty their shopping cart.
If you're using ASP.NET here's what I'm (about) to do:
use a Profile to capture the users email as soon as possible (to email them if they dont complete the order). you can enable anonymous profile properties that are persisted to the aspnet database even if the user hasnt actually truly registered.
stick an XML bag representing an order into session. This is persisted in the database with a regular identity ID.
store the ID of the cart in the ASP.NET Profile. that way when the session expires you can just reload it from the ID in the profile. this has the benefit that the user never sees the cart ID in a cookie and you can easily link records between the membership/profile database and the store you're using for your orders
(dont try to store the XML order in the Profile. i think thats asking for performance issues. but in theory you could i suppose)
With those specs I would go with a database based session state. But you should do some heavy reading on how session state is handled in your web server of choice. Since you want to be able to revive the state to the correct person.
I think you have some expectations to manage, or maybe you weren't clear on requirements.
The user experience guys want login/authentication to be the very
last step in the entire work flow. The
user gets to do all the shopping and
is asked to login only at the time of
checking out.
The shopping cart shouldn't expire(not even on browser close)
unless the user (registered or not)
does check-out.
Specifically, an anonymous, not logged-in user's cart being saved? That's madness. Ensure that's not an expectation and clarify it in your design documents.