Skip Menu |

This queue is for tickets about the Apache-AuthCookie CPAN distribution.

Report information
The Basics
Id: 44803
Status: resolved
Priority: 0/
Queue: Apache-AuthCookie

People
Owner: Nobody in particular
Requestors: rogerbush8 [...] yahoo.com
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: Bug: Apache::AuthCookie 3.12 "WhateverExpires" setvar not working as expected
Date: Sun, 5 Apr 2009 08:50:29 -0700 (PDT)
To: bug-Apache-AuthCookie [...] rt.cpan.org
From: roger bush <rogerbush8 [...] yahoo.com>
Bug report: Apache2::AuthCookie 3.12 perl v5.10.0 Darwin owncloselady-lm 9.6.0 Darwin Kernel Version 9.6.0: Mon Nov 24 17:37:00 PST 2008; root:xnu-1228.9.59~1/RELEASE_I386 i386 i386 I'm experimenting with the following PerlSetVars for this module PerlSetVar WhateverSessionTimeout +1m PerlSetVar WhateverExpires +2m I've looked through docs and code to figure these out, and WhateverExpires doesn't seem to behave as expected. WhateverSessionTimeout works fine, as an "inactivity timer" (cookie gets reset with each request). I had thought WhateverExpires was a "max time until need to login again" (otherwise I'm not sure what the point is). However WhateverExpires is constantly resetting the cookie expiration (visible in browser cookie window as "Expires"). Shouldn't WhateverExpires _not_ be reset, but copied to the next cookie sent out? Thanks, Roger
On Sun Apr 05 11:50:51 2009, rogerbush8@yahoo.com wrote: Show quoted text
> I'm experimenting with the following PerlSetVars for this module > > PerlSetVar WhateverSessionTimeout +1m > PerlSetVar WhateverExpires +2m
Its not really clear from the docs, but you probably only want one of these, not both. That is the main reason both of these settings exist. Using SessionTimeout, the cookie expiration date is advanced each time the user requests an authenticated page. As you have already figured out, this is like an idle-logout feature. Using Expires, the cookie expiration is set with an expiration timestamp when they authenticate, and the cookie will not be updated (unless you update it yourself). The cookie will simply expire at the specified time. This also makes the cookie persist across browser restarts. If you do not set either one of these, then the cookies will be "session" cookies. In other words, no expires field will be included in the cookie (browser discards when it exits). If you want a combination of idle timeouts, as well as a hard expiration, you need to do this as part of your authen_ses_key() routine. This is really the only foolproof way to do it anyway because you can include a signature in the cookie value to ensure it has not been tampered with. See Apache::AuthTicket for one possible implementation of this. AuthTicket stores a time() value as one of the fields in the cookie. This is the time that the cookie will hard-timeout (user must log in again after this time no matter what). This timestamp is checked by the authen_ses_key() method on each request. To get the "idle logout" feature, AuthTicket stores "last accessed" timestamps for each cookie in a database and checks that as part of the authen_ses_key() as well. Another approach, that would avoid the database, is to just use SessionTimeout. That would give you the idle-logout feature, but you would need to handle the hard expiration due to the fact that SessionTimeout will keep updating the expires field. You would use the same idea here. Include the "hard timeout" timestamp in the session key that the cookie should "expire", and check it in authen_ses_key(). Also, if you want to make sure that the client has not tampered with the ticket, you should include a signature in the session key as well (e.g.: SHA256 of the key fields plus some secret value.. see AuthTicket for example implementation). Regards, Michael Schout