Steve Clay wrote:

> Hello,
>       I'm building an e-commerce site which uses sessions to
> hold my $cart object.  This works great but I've two worries:
> 1) When the user connects through our secure hostname, can I ensure
> the browser will send the server the cookie (w/ SESSID)?  The user
> will shop through and checkout via
> (haven't got cert yet)

If your "cookie domain" is "", it will send the cookie to
both, however, you don't really WANT to use the same cookie in both

> 2) While the user shops the SESSID is thrown around insecurely (no big
> deal, just a cart).  But when I move the user to a secure server to
> get sensitive info a resourceful hacker could also go to the checkout
> script using this SESSID and 'confirm' the real user's personal
> details (kept in another registered session object).

Yes, and so this is inappropriate. Allocate a cookie for all pages (ssl
and not). When they transition to SSL for checkout, then give them an
SSL cookie as well, and associate it with the old cookie. You could store
them in a session -- I do it in a database table. Store the time you
allocated the SSL cookie. Mandate that when someone views a secure page, to
be considered authenticated, they must hand you the SSL-only cookie. You
can use its association to retrieve the cart, but not to let someone else 
interrupt the ordering process, or use its authentication properties to
view personal details, cancel an order, etc. Since you set the cookie to
be SSL-ONLY (there's a flag for that in setcookie()), it won't be passed
in the clear. Associate the assignment time of the cookie with it, and each
pageview, reset it to some reasonable number, say 5-30 min. After that time
expires, the cookie is no good and you reassign one. In my own scheme, that's
when a user re-enters their password.

Anyhow, the dual-cookie approach will allow you to maintain reasonable


PHP General Mailing List (
To unsubscribe, visit:

Reply via email to