On Thu, May 19, 2011 at 8:14 AM, David Precious <davidp@preshweb.co.uk> wrote:
On Thursday 19 May 2011 15:32:02 Brian E. Lozier wrote:
I would be interested in this as well. The other problem that I haven't had time to resolve yet is that using the built-in session interface (no matter the plugin as far as I can tell) I can't set a custom session timeout (based on form input, for example).
You can control it with the session_expires config setting.
This wasn't well documented in Dancer::Config; it is now.
I don't see much about sessions in Dancer::Config. It just tells you you can enable sessions with the session engine. The most detail I can find is here: http://search.cpan.org/~xsawyerx/Dancer-1.3040/lib/Dancer/Session/Abstract.p... I think that's a global setting and not really what I'm talking about. If I'm completely missing something please correct me. This thread reminded me that I'd like to not have sessions enabled for all accesses, only for logged in users. However, I have been using one of the flash message plugins which require sessions for every user anyway so it's not a big deal at this point. However, this issue about sessions expiring keeps coming up for me. So pretend for a moment that I do not want a session for every user, only for logged-in users (thus, I would be creating the session). There are two things I'd like to accomplish: 1. A log in page where user doesn't check a "remember me" box. I would check user credentials, create a session, and send a cookie to the user that expires when the browser closes. This is a "session cookie" from the HTTP standpoint: http://en.wikipedia.org/wiki/HTTP_cookie#Session_cookie I would of course still keep a reasonable expire time on the server. However, in this case it's really nice to expire not only the session on the server but also the session cookie on the client so we don't leave cookies hanging around forever on client machines. 2. A log in page where user DOES check a "remember me" box. In this case I would check user credentials and then send a persistent cookie that expires at some point in the far future (like a year). http://en.wikipedia.org/wiki/HTTP_cookie#Persistent_cookie I would also set their session on the server to persist for at that amount of time. The problem (that may not be a problem if I'm misunderstanding something) is that I can't set the expire time of these session cookies on a per-request basis. Dancer creates the session cookies before I even have a chance to do anything. Dancer's session interface is nice and simple but makes it impossible to programmatically control the cookie expiration. It's set in stone (in config) when the request starts. Even if I override it in one of my routes, maybe it will work for that request, but next time the user visits some other page the cookie will be reset to whatever is in config. I have a couple of options: 1. Don't use dancer session interface for my login cookies/sessions. This will allow me to control both the server and client side expirations. 2. Never expire client side cookies and when the user doesn't check the box just expire the session sooner on the server side. If I set the server expire too short, it will annoy users (because they're still browsing in the same browser session and I expired them), but if I set it too long, it will persist across browser closes. Users expect that if they're logged into a site and they didn't check this box, when they exit the browser they will be logged out. With a persistent cookie it's impossible for me to detect whether the browser was closed between requests. I'm going to end up using option #1 because option #2 is cumbersome and unreasonable (and can be insecure, for example, on public terminals at libraries). Dancer sessions are nice but the interface to them is too limited and the fact that they are created all the time, instead of just when needed, is problematic for me. I would like one that only creates the session when session() is used and session() should take an argument for client-side cookie expiration.
-- David Precious <davidp@preshweb.co.uk> (bigpresh) http://www.preshweb.co.uk/
"Programming is like sex. One mistake and you have to support it for the rest of your life". (Michael Sinz) _______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users