Rodrigo Castillo wrote:
> I'm exploring the rcmail_session class to hunt down some intermittent
> issues with untimely session expiration, and to develop a better
> remember_me extension (or attempt to get it into core...).
>
> I came across the following code
>
> ...
> /**
> * Setter for session lifetime
> */
> public function set_lifetime($lifetime)
> {
> $this->lifetime = max(120, $lifetime);
>
> // valid time range is now - 1/2 lifetime to now + 1/2 lifetime
> $now = time();
> $this->now = $now - ($now % ($this->lifetime / 2));
> }
> ...
> /**
>
> * Create session cookie from session data
> *
> * @param int Time slot to use
> */
> function _mkcookie($timeslot)
> {
> $auth_string = "$this->key,$this->secret,$timeslot";
> return "S" . (function_exists('sha1') ? sha1($auth_string) :
> md5($auth_string));
> }
> ...
> /**
> * Check session authentication cookie
> *
> * @return boolean True if valid, False if not
> */
> function check_auth()
> {
> ...
> if ($result && $this->_mkcookie($this->now) != $this->cookie) {
> ...
> }
>
> It's quite deliberate, and it made me curious as to the reasoning behind
> the decision not to simply include a 'created_at' and 'expires_at' within
> the cookie, which would simplify the validation of the timespan. Is the
> reason for security, or perhaps a load-balancing?
The main reasons to encode a "timeslot" into the second cookie are:
* Have a cookie that changes its value during a session in order to reduce
the risk of session hijacking.
* Having the timeslot encoded in the cookie hash, it's kind of state-less
and we don't need to update the actual session data on every request just
to extend the expiration date.
Regards,
Thomas
_______________________________________________
Roundcube Development discussion mailing list
[email protected]
http://lists.roundcube.net/mailman/listinfo/dev
