Purpose of cookie + session vs only cookie

skyhrg

Hi,

I'm reading Head First PHP and the book talks about how superior the persistence is for using both cookies and session variables by resetting the session variables from existing cookie variables when you open up the browser again.

But when you think about it, what's the point of using sessions again in addition to cookies, if when you're using both the cookies are already exposed? That is, I'm not talking about session ID cookies here, I'm talking about just copying the cookie variables straight onto the session variables - not getting an address or anything like that.

Weedpacket

Why does the book say it's superior? What reasons are given there?

traq

skyhrg;11030949 wrote:
using both cookies and session variables [and] resetting the session variables from existing cookie variables when you open up the browser again.

The only possible use case for this is to deliberately introduce a code injection vulnerability. Find a new book.

skyhrg

You're right. The book is elementary level but even I could understand that it was pointless and possibly dangerous.

Is there anyway I could combine the security of sessions(compared to cookies) while not losing the session when the browser closes?

bradgrafelman

The session is only "lost" when: a) PHP's session garbage collection routine is randomly triggered AND it determines that the session hasn't been used for some minimum amount of time, OR b) when the user's browser loses the session ID (e.g. if using cookies to propagate the SID, the cookie expires).

So, all you need to do is prevent both (a) and (b) from happening. For the former, make sure your session settings are configured appropriately in your php.ini config file - see session.gc-probability and the two "gc" directives that follow. For the latter, you can again ensure your php.ini is configured as desired (see session.cookie-lifetime) or utilize [man]session_set_cookie_params/man every time before you call session_start().

skyhrg

Weedpacket;11030959 wrote:
Why does the book say it's superior? What reasons are given there?

For best "persistence" - that is, the browser remembering the user that's logging in. Cookies expire, and sessions are lost when browser closes. The book doesn't really explain much on why it's using cookies with sessions, when session cookies are usually used, and the cookie variables are simply copy and pasted unto the session variables - this doesn't make sense.

BTW, the book is published in 2009. Perhaps that may explain a little. And to be fair, the rest of the book has been pretty good.

bradgrafelman

skyhrg;11030975 wrote:
For best "persistence" - that is, the browser remembering the user that's logging in. Cookies expire, and sessions are lost when browser closes.

Cookies (usually) expire when you tell them to. So, if you want the session to persist longer than just the current browser session, then configure the session cookies to expire sometime after that.

In other words, the sole justification the book appears to have for doing something strange and, IMHO, a bad practice, is now moot. This makes me wonder just how valid this statement really is:

skyhrg;11030975 wrote:
the rest of the book has been pretty good.

sneakyimp

Cookies expire, and sessions are lost when browser closes.

As bg said, you can specify pretty much any expiration date you want for a cookie. The idea with sessions is that you put a session ID into a cookie on the user's machine and your server maintains a session on the server for that particular session ID. As long as the user hangs onto the session ID, they can come back and ask the server to resume their session. If your server deletes the data corresponding to a particular session ID then it won't have the data when the user comes around again.

skyhrg

Yes I agree with everything - the book just didn't make sense so I just wanted to double check whether I had missed anything.