Difference between revisions of "VbzCart/pieces/sessions"
| Line 1: | Line 1: | ||
| − | [[Technology]]: [[VbzCart]]: [[VbzCart | + | [[Technology]]: [[VbzCart]]: [[VbzCart Session|Session]] |
| − | ==Identifying | + | A [[VbzCart Session|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). |
| + | |||
| + | ==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 15: | ||
==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 |
Revision as of 22:02, 25 July 2005
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).
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: