VbzCart/docs/pieces/sessions: Difference between revisions
imported>Woozle No edit summary |
m (Woozle moved page VbzCart/VbzCart/pieces/sessions to VbzCart/docs/pieces/sessions without leaving a redirect: correct naming (was no way to import directly to this name)) |
||
(7 intermediate revisions by one other user not shown) | |||
Line 1: | Line 1: | ||
==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. | |||
==Identifying | 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. | 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. | 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: | What I've come up with is the following: | ||
Line 13: | Line 20: | ||
==Sequence of Events== | ==Sequence of Events== | ||
*On receiving one or more items to add to the cart: | *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 |
Latest revision as of 01:53, 25 February 2024
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: