How to keep sessions alive

[sirugo]

I have a script that reads a cookie from which it creates remote sessions. The problem is that the session does not survive long enough.

Is there a safe way to handle the time for how long a session should last? A good way would be to extend its lifetime for an hour each time a page is read.

 

[jpadie]

you could either play with session entropy in your php.ini file or
perhaps store your session variables in a database. on each page load:

+ wipe all rows with a timestamp over 1 hour
+ change the timestamp of the row keyed on the current cookie value.

 

[sirugo]

Thanks

I considered both.
But I was aiming at the php.ini because somewhere I read that it's rather easy to manipulate the content of a cookie file so if a user wants to convert himself he could do that in the cookie? Or I could md5 the content of the cookie. But still I'd like to avoid plow through the database. Also I read somewhere that setting the php.ini values that handle lifetimes of sessions are not always working as expected. Many thoughts here. Anyone with more suggestions on this one?
And...exactly which parameters must be set in the php.ini?
session_set_cookie_params is something to be used?
Good or bad?

 

[sleipnir214]

sirugo:
You need to understand how session cookies work. What is stored in the user's browser in the cookie is not the session data. All that is stored is the index which identified the session store on the server. PHP uses the value sent by the browser to know which session store to open when a script issues session_start().

If a user were to manipulate the value of his session cookie, the chances are all he would do us make it impossible for PHP to find his session data. PHP doesn't assign sequential session indeces.

For an idea of how php.ini values affect cookies, take a look at faq434-4908



Want the best answers? Ask the best questions! TANSTAAFL!

 

[sirugo]

I know that.
What I meant was that the user might be able to change the value of a cookie (not the session-cookie). If it's the origin of the session he would thereby be able to "become" someone else in the session. As far as I know a session value is not that easily changed.

So all I need to know is how to prolong the lifetime of a session to force the user to stay alive.

I'll take a look at that other thread now.

 

[sirugo]

An example:

A user visits a site. He logs in. He wants to "stay logged in" also after days from that moment. A cookie is stored with the username. When the user returns the site reads the cookie and creates a session (with the session cookie on the server). Now, what if the user changes the value of the cookie I first mentioned. Wouldn't that mean that he automatically be logged in as someone else? Hasn't he hacked the site? Unless they have encrypted the username in the cookie/database?

 

[sleipnir214]

For something like that, I generally make the "logged-in forever" cookie's value a hash of multiple things concatentated together. Ir makes it easy to detect tweaking.



Want the best answers? Ask the best questions! TANSTAAFL!

 

[sirugo]

So, are you actually doing this:

Each time a page is called at the site, you are retrieving the hash from the client cookie and you're comparing it to entries in your database to see if the same hash (based on username etc) exists there?

 

[sleipnir214]

Yes.

A hostile entity may be able to get hold of other userids, etc. But he won't know the additional data you've used with the user data to produce the hash.



Want the best answers? Ask the best questions! TANSTAAFL!

 

[sirugo]

And it's not a heavy load for the server to do this search fo every page that's called?

 

[sleipnir214]

Hashes, by definition, require low calculation overhead. And you can always precalculate the hashes for all entries in a database and store them as an additional column in each record.

But whaterver method you use, the trick is to make guessing an existing additional set of data very difficult.



Want the best answers? Ask the best questions! TANSTAAFL!

 

[sirugo]

Thanks.
This sounds pretty safe and a lot easier to handle than all sessioning.

 

[sleipnir214]

Oh, I'd still use sessions for moment-to-moment state maintenance. PHP does a pretty good job of generating non-sequential session indeces.

The hash cookie idea was just for the "remember my login" question.



Want the best answers? Ask the best questions! TANSTAAFL!

 

[sirugo]

OK, but my main problem was "always logged in".
I'll see if I will be needing sessions. I'm not sure yet.