#14579: built-in sessions middleware can't be used for entirely cookie-based
sessions
------------------------------------+---------------------------------------
Reporter: oran | Owner: nobody
Status: new | Milestone:
Component: Uncategorized | Version: 1.2
Resolution: | Keywords:
Stage: Accepted | Has_patch: 0
Needs_docs: 0 | Needs_tests: 0
Needs_better_patch: 0 |
------------------------------------+---------------------------------------
Changes (by lukeplant):
* stage: Unreviewed => Accepted
Comment:
It would definitely be nice to make an entirely cookie based session
backend possible without patching Django. The patch as it is requires a
fair bit of work:
1. Unified diff please! Taken from the root of the django src. And
preferably not backwards. It's extremely difficult to understand
otherwise, and very fragile to apply.
2. Tests needed
3. Docs needed
4. Do we really need to check whether 'request' and 'response' attributes
exist before adding them?
But, more substantially: Is there actually some nicer way of giving the
session access to the request and response objects? The method provided
works (if I read the patch correctly, which is difficult), but is pretty
ugly:
* 'request' and 'response' are not passed in explicitly anywhere to a
`SessionStore` method. This is a very unobvious API from the point of view
of implementing the backend - you have to know exactly when the request
and response objects are going to appear.
* a custom 'put_in_cookie' method which needs explicit support in the
middleware. It is special casing for this one backend that doesn't help
any other backend.
Essentially this requirement needs a slightly different API to the one
provided by `SessionStore`. Our normal way of handling this is to
deprecate the existing API and migrate to a new, better one, gradually if
it is possible - like [http://docs.djangoproject.com/en/1.2/topics/auth
/#handling-object-permissions object permissions in the auth backend]. In
this case, I think we need something like a `SessionBase.save_to_response`
method, whose default implementation contains some of the code from the
session middleware. The obvious place to pass in the request would be the
`__init__` method, which would not be backwards compatible.
To cater for these two, a custom class attribute (or more than one) could
be used to distinguish the new API from the old.
This has already turned into a significant piece of work, sorry about
that...
As the for the actual implementation of the backend, there are a lot more
issues if it were to be considered for inclusion into Django, but I won't
go into that.
--
Ticket URL: <http://code.djangoproject.com/ticket/14579#comment:2>
Django <http://code.djangoproject.com/>
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?hl=en.
