Jump to content
Larry Ullman's Book Forums

Best Way To Use Sessions On Checking Out - Logging In, And Logging Out


Recommended Posts

HI All,

 

Im a little confused as to the best way to approach the dealings with sessions when checking out, logging in, and logging out, in example 1, larry starts the session in the config which is included in every page to help follow the user, in example 2 however, only cookkies are used until the checkout process, now what i am wanting to do is implement user registration on ecommerce which allows users to login and complete checkout but also give the option to checkout as a guest, without the user being registered,

 

my question is, whats the best way to track users? as logging in starts the session and logging out destroys the session, so if a user logs out will all items in cart be empty ?

 

im bascially trying to implement both examples in the book, any help or input would be much appreciated.

 

thanks guys! :)

Link to comment
Share on other sites

Good question! You're conflating a couple of issues here, so I'll separate them. First, a cookie is used to identify the user. The first example uses a session cookie and the second uses a non-session cookie. The benefit of the latter is it's intended to last for a longer time. 

 

Second, the identifier (via a cookie) can be associated with data stored on the server. With a session, the data is stored--for a short time before being automatically deleted--in text files (by default). With the second example in the book, the data is stored--until it's manually deleted--in the database. 

 

If you wanted to use a session but have the cart items persist, you'd store the cart items in a database (linked to the logged in user's ID), not in the session itself. 

Link to comment
Share on other sites

HI Larry,

 

in example 2, cookies are used when a user first visits the site, however the session starts at checkout, would it not be best to use cookies and sessions only to avoid superfluous build up of frivolous data in the database? if i were to have 2 tables, USERS for my registered users and CUSTOMERS data for any customer to make a purchase as a guest and just tie that data to either a user id if the user is registered with a user id set in session, or customer id if the user is not registered and is only checking out as a guest, this way if the user some how managed to alter the session id inside the cookie on their browser, the worst thing that could happen would be that no items would be set in the cart but a new session would start with the id the user altered. did you get all that ? hope so

 

cheers

Link to comment
Share on other sites

Ah...right! Sorry about the confusion on that. Yes, in example 2, a cookie is used for long-term, non-authenticated user history whereas the session is used for a short-term, authenticated checkout. 

 

Personally, I would not create two separate tables. The main thing that differentiates a registered user from a guest is the registered user can log in. Two separate tables would result in a lot of duplicated code and effort.

 

I guess I may not still be clear on what problem you're trying to solve here. Instead of putting this in terms of what the book does, how about explaining what you hope to achieve and I can comment on that?

Link to comment
Share on other sites

HI Larry,

 

what i am trying to achieve is a common approach of allowing a user to checkout without being a registered member as the example does, however i want to implement a registration system in the site, and know the best way of holding data in a cookie or session and knowing the best time to switch the data over from the cookie to the session.

 

Should i start the session on every page and when a user logs in just add user_id to the session and delete it when they log out? or use cookies only until a user logs in or a non-user reaches the checkout page ?

 

one more thing, how can i setup an area where  a non user could check or track their order?

 

thank you!

Link to comment
Share on other sites

If it's just a matter of allowing a user to checkout without registering, use sessions. You'll need to start the session on every page so the session is maintained from the very beginning. The only downside is if the user goes away and comes back (hours later or days later), they'll need to redo anything they had done (i.e., their session data will be lost). 

 

Yes, when/if a user logs in, you can add additional info to the session then. 

 

To set up a view/track order page, you'd want to use 2 or more unique identifiers: the order ID and the email address used would make sense. You'd only show the order information if both are correct. (Alternatively, if you're shipping products, the destination postal code is often used.)

Link to comment
Share on other sites

thanks for the reply Larry, to save the session data i will save it to a database table, and save that session data assigned to a user id which would of course be of a registered user, but how would i save session data for just a guest ? create a separate table for just guests?

 

thanks!

Link to comment
Share on other sites

Session data isn't saved to the database in that way. If you actually store session data in the database (as opposed to the standard file system), all the data goes in one column, so it doesn't matter whether or not the data is storing the user ID. The same database table structure would be used whether the session stores 1 thing or 20. 

Link to comment
Share on other sites

but that's only if i store the $_SESSION variable into a column into a table in the database, for example, if i had a table called "cartdata" could i not do this ?

 

INSERT INTO cartdata (customer_id, user_session_id, sku, quantity) VALUES ($_SESSION['cid'], $_SESSION['uid'], $_GET['product_sku'], 1)

 

before i run the query, i would check to see if customer_id is set, if not, i will use user_session_id, however the table will encounter null values in some columns due to this, so i was thinking of making a seperate table for guests. 

 

what your thoughts?

Link to comment
Share on other sites

Well...the thing is...technically, if you do what you propose, you're not storing the session data in a database. You're storing data in a database, some of which comes from a session. This is not the same. 

 

You said you wanted to "avoid superfluous build up of frivolous data in the database". Why not store the data in a session (for real) and only populate a database table upon completion of the checkout? 

Link to comment
Share on other sites

 Share

×
×
  • Create New...