Difference between revisions of "VbzCart/pieces/sessions"
m (Woozle moved page VbzCart Session to VbzCart/session without leaving a redirect) |
(post-import note about being dated) |
||
| Line 1: | Line 1: | ||
| − | + | ==Note== | |
| − | + | This documentation was last edited in 2008, and should be checked for accuracy. | |
| − | A | + | ==About== |
| + | A '''session''' is when a particular user is connected to [[VbzCart]] using a particular browser on a particular computer. | ||
Multiple carts may be created in a single session, as well as multiple orders. The same cart may not be accessed from different sessions; the user needs to save the cart to something which can be identified humanly, i.e. an order (or, in the future, perhaps a wish list). | Multiple carts may be created in a single session, as well as multiple orders. The same cart may not be accessed from different sessions; the user needs to save the cart to something which can be identified humanly, i.e. an order (or, in the future, perhaps a wish list). | ||
Revision as of 03:27, 21 December 2012
Note
This documentation was last edited in 2008, and should be checked for accuracy.
About
A session is when a particular user is connected to VbzCart using a particular browser on a particular computer.
Multiple carts may be created in a single session, as well as multiple orders. The same cart may not be accessed from different sessions; the user needs to save the cart to something which can be identified humanly, i.e. an order (or, in the future, perhaps a wish list).
A session also helps keep track of user preferences, e.g. searching only certain item types or topics.
Identifying a Session
I've been debating about the idea of allowing carts to work using IP address/domain plus browser ID (user_agent) because cookies don't always seem to work (and some people have them turned off), and I think I've come up with a reasonable compromise.
The problem is that one user might connect through a dial-up (dynamic IP), place orders in a cart and disconnect, and then another user with the same browser and OS might happen to connect through the same dial-up -- which would cause that user to be assigned the previous user's shopping cart. This isn't a serious problem, because no personal information will be conveyed, but it can be off-putting to go to a store and find that your cart already has items in it. I would be inclined to immediately go somewhere else if I encountered this.
What I've come up with is the following:
- sessions IDed via IP/browser have a much shorter expiration than cookie sessions
- sessions IDed via IP/browser will show a warning to indicate the shorter expiration time (should show the time when the session will expire -- and the current time, to prevent timezone confusion)
- cookies have never been used for checkout; we have always used POST data (?session=xxxxx), so that's not an issue
Sequence of Events
- On receiving one or more items to add to the cart:
- Try to match with existing session:
- Check for session cookie; if found, use that
- If no session cookie, look for unexpired IP/browser match
- If no usable existing session found, create a new one (empty cart)
- Add items to the session cart
- Display cart & session info
- Try to match with existing session: