stay logged in in php application for +1 week

Strictly speaking you do not need sessions. You are confusing two things:

Sessions are used to store data server-side for a specific user. This will probably include the user name with which the user the logged in. Sessions are typically relatively short-lived (e.g. expire after a few minutes or hours of inactivity). Session cookies (i.e., cookies that expire after the user closes the browser) are typically used to associate a given user to a given session, though other other methods can be used, such as passing the session id in the URL (beware of session fixation in this case).
For long lived logins, one typically stores the user credentials or some medium-term user credentials surrogate in a non-session cookie that's set to expire after a few weeks or months. Whenever the user does not have an active session associated with him, these credentials are used to initiate such session without user interaction.

So basically, cookies are used for two purposes – to store a short-lived (minites or hours) session id and to store user credentials for a few days/weeks/months.

are you saying that we should keep sessions for one week? wouldn't that be using up session table data/memory? Or is that something that's not really a big problem, even with a lot of users?

Jorre 2010-07-10 11:04:57

@Jorre that depends on what you throw into the Session Storage and what *a lot* of users are and what hardware capacity the system has. Sooner or later any system will reach it's capacity.

Gordon 2010-07-10 11:14:45

I disagree to the second bullet point. Never use credentials in a Cookie. This is insecure. Also, there is no reason why the Session or it's cookie should be short lived. The Session Cookie being removed when the browser is closed is just the default setting. This can very much be changed to anything you want.

Gordon 2010-07-10 10:44:16

@Gordon It's only insecure if you make if it insecure. You can mark the cookie secure and then it'll only be sent via https.

Artefacto 2010-07-10 10:46:41

That would only use HTTPS from the client to the server. Also, I dont see why I should use a second cookie when this can easily be handled with the Session Cookie alone. Just up the lifetime.

Gordon 2010-07-10 10:49:30

@Gordon What? In SSL/TLS it's not possible for a party to send unencrypted data while the other does -- what do you mean it "would only use HTTPS from the client to the server"?

Artefacto 2010-07-10 10:56:40

I might be wrong, but see the description for [setcookie](http://de2.php.net/manual/en/function.setcookie.php) on the secure flag. But my main point is that you simply dont need a second cookie anyway.

Gordon 2010-07-10 10:58:45

@Gordon OK, I'll translate that description. Let's say the client has a cookie stored with the secure flag set. The client initiates an unencrypted connection to the relevant website – result: the cookie's not sent. Now, the client starts an encrypted with the same site – result: the cookie's sent. What the second part means is that the site may set the secure cookie both through an encrypted connection an through an unencrypted connection – though it would be stupid to do so through an unencrypted one.

Artefacto 2010-07-10 11:05:56

@Gordon There are several reasons why may not want to use very long lived sessions – storage taken by the sessions, not wanting to mess with session garbage collection in PHP, because several things are cached in the session and deleting the session is the form of cache invalidation used, etc.

Artefacto 2010-07-10 11:08:08

Yes. That's what I understood, hence only only from client to server. But still, what I really dont see is what the second cookie should be good for? If the session expired, then all the data associated with it is gone unless you persisted it somewhere. Why not just keep the session active through the session cookie then? Unless you throw megabyte after megabyte into it, space shouldnt be a problem.

Gordon 2010-07-10 11:09:15

@Gordon No, you don't need a session cookie if you change the expiration and the session save path (for file based sessions). However, using two cookies may be the easiest migration path for a system that currently relies on sessions being short (e.g. has stale cache a few times; for instance, the groups a user belongs to). It also allows using short-lived insecure session cookies that are transmitted via unencrypted connections for not-particularly-important stuff and a protected user/pass surrogate cookie for the important actions. So, what's more appropriate will depend.

Artefacto 2010-07-10 11:41:05

Hmm, okay. Guess I just never ran into the need for this. I think I can agree to it then. Thanks for sharing :) - do you want me to clean up comments?

Gordon 2010-07-10 11:48:53

@Gordon I'd save the exchange for the posterity.

Artefacto 2010-07-10 11:55:49

You still use cookies to implement sessions, if someone intercepts the cookie he can hijack the session. So really, it doesn't make much sense to present a session vs cookies dichotomy. Session is a different, more abstract concept and cookies are a common piece in the implementation of such concept.

Artefacto 2010-07-10 10:53:13

Session uses cookie, that's written in my 1st sentence. However, if cookie is stolen server still may compare user's IP and reject auto-entering. That's also mentioned ;)

Denis Chmel 2010-07-10 21:40:13

ansaurus

tags:

views:

answers:

stay logged in in php application for +1 week

related questions