#2548: [PATCH] Add set/get_expires methods and expires propery to sessions
--------------------------+-------------------------------------------------
Reporter: Tsume | Owner: adrian
Type: enhancement | Status: new
Priority: normal | Milestone:
Component: Contrib apps | Version:
Severity: normal | Resolution:
Keywords: sessions |
--------------------------+-------------------------------------------------
Comment (by mtredinnick):
I am assuming this is being done at the request level to allow per-user
preference settings? Otherwise, I also need the use-case clarified (which
hasn't been done so far).
To address one part of the last comment: All cookie and session
information should definitely not be adjustable by the programmer on per-
request basis. It will break things. You can already adjust all those
values on a project-wide basis. And if you have multiple sites for the one
project, it is per-site configurable (since they use different settings
files). That being said, the patch as it stands looks reasonable, but the
extra things Adrian mentioned probably don't work.
We can't have SESSION_COOKIE_NAME being configurable on a per-user basis,
because then we would not know which cookie to parse for the session
information. It has to be project-wide constant. Similarly,
SESSION_COOKIE_DOMAIN shouldn't be configurable on a per-user basis
because if you are really operating out of multiple domains and sub-
domains and paths, everything is going to be wanting to work with the
cookie and the apps outside the current user's *_DOMAIN setting are going
to think the cookie isn't set and create it (and stomp on the existing
one). You can't have multiple cookies with the same name and overlapping
domains. I think SESSION_COOKIE_SECURE is going to have the same problems:
it means that HTTP-based cookies and access to the site are a possibility
and how will the session code know the difference between "doesn't have a
session cookie yet" and "only has the session cookie available via HTTPS"?
It can't look up the user's preferences, because it doesn't have that
information.
I can see a case for per-user session timeouts, though. On sites where the
security is somewhat left up to the user (how aggressively do you want the
site to time you out?), per-user timeouts are needed. We can't do that at
the moment. That's an actual use case. So I would be +1 on the patch as it
currently stands.
I would be -1 on adding things like the ability to set "3 weeks". This is
a developer API. They can do the maths for the possibilities they want to
offer. Adding all that extra code into core for all the possible date
types we might offer just to avoid a couple of multiplications increases
the amount of code we have to maintain and answer questions about.
--
Ticket URL: <http://code.djangoproject.com/ticket/2548>
Django <http://code.djangoproject.org/>
The web framework for perfectionists with deadlines.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-updates
-~----------~----~----~----~------~----~------~--~---
