solved Logging in creates a new session. Good or bad?

[apeisa]

I have settled down using $session variable instead of superglobal $_SESSION. There is one big difference though. If user logs in then PW $session is lost and new one is acquired. I don't know if that is intended behavior?

I realized this on my shopping cart module since people lose their carts after logging in. Of course I could start using $_SESSION here, but wanted to ask first if $session works right and if it does, why it is so?

[ryan]

I can modify our $session to copy data, that would make sense. It just never came up before, but lt me see if I can add this. Though you may actually want to use a cookie rather than a session for cart data, just so that the cart data can live longer than the session (there isn't really any reason for it to expire as quickly as a session does). Also want to mention that PW uses PHP's $_SESSION as well (keeping it's data in an array inside of it), so it's not a problem to use $_SESSION rather than $session.

[apeisa]

Thanks for the reply. This is first time I encountered this too, so no need to make changes because of this. You are probably right about using cookies in this situation. Default lifetime for session is pretty short. Although I would probably want to fallback to sessions in that case, since some people have cookies disabled. Not sure about percentages, but last time I checked it was pretty high. Couldn't find very recent data, but http://smorgasbork.com/component/content/article/84-a-study-of-internet-users-cookie-and-javascript-settings (US, 2009 and 3.4% had cookies disabled).

If someone knows more recent studies on cookie usage, please do share

[WillyC]

fall back you must avoid

sessions fathered by cookies they are

session id in url come from dark side.safe is not

[ryan]

I think what WillyC is saying here is that sessions come from cookies and are only a fallback if you use URL-based sessions, where a session ID is passed along in the URL. But that type of session is considered a security problem, and they are disabled in ProcessWire by default. My opinion is that people browsing without cookies probably don't want to be tracked. If they have cookies disabled, they probably aren't able to do much anywhere. I could be wrong, but I don't think there are many stores that will let you build a cart and complete a transaction without cookies (?). I guess that using HTML5 storage, Flash or even a browser's file/image cache could be alternative ways to maintain session data.

[apeisa]

Ok, now I get it... PHP itself uses cookies to keep session_id on client. And if client has disallowed cookies then it fallbacks to url-based session (which is disabled by default on PW). I somehow had believed that there is some other method how PHP session works, but good that I don't believe so anymore Thanks Yoda & Ryan! (But I have heard that power is so much stronger on the dark side?)

I did some testing and it seems that PW uses session key called wire. But after login there is two cookies, wire & wire_challenge. Is that wire_challenge some hash that is calculated against user agent data? Can you share more information about how PW handles session security?

[ryan]

The session challenge cookie is a randomly generated hash with one copy in the session data (at the server) and another copy in a separate cookie. The two have to match in order for the session to be considered valid. The value is set at login time. It's basically just a secondary session ID for a little extra security. If someone finds out your session ID (via a URL or some other means) they would also have to have your session challenge key in order to intercept that session.

There is also the session fingerprint which is kept only in the session data (at the server). This is a record of your IP and user agent. If either changes, the session is no longer valid. This is turned on by default (in config.php) but should probably be disabled for an online store, since you may be dealing with folks that have dynamic IP addresses. Though if you are using your own cookies for the cart, then it should be fine to leave the fingerprint check in place (where it would be more for admin users).

[apeisa]

Thanks Ryan.

What I will do is probably this: I will use cookie wire_shop that keeps value which is initially same than the session_id (wire cookie value). If you login, then it will save your user_id to my active carts table and use that to identify you and your cart.

If you don't login, but close browser and come back with new session, (but still with wire_shop cookie), it will look for active carts table, find your old cart and use that instead.