#25392: Allow contrib.auth to work without sessions
------------------------------+--------------------------------------
Reporter: rdaysky | Owner: nobody
Type: New feature | Status: new
Component: contrib.auth | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
------------------------------+--------------------------------------
Comment (by rdaysky):
The changes don’t look profound to me.
Firstly, contrib.auth has only a few references to request.session, none
of which are essential. Just putting an if hasattr(request, "session")
prior to such code will do. This makes, for example, auth.login only set a
non-persistent request.user, but additional functionality such as emitting
a signal is preserved.
Secondly, when session middleware is used for some requests, but not
others (e. g. using the Django admin on an otherwise API-only site), there
should be a way to login a user without touching the session. Currently,
request.user = get_whatever_user() works just fine, but using an
officially supported function would be better, something like
auth.login(request, user_I_just_found_in_the_DB,
persist_in_session=False). Would also have the benefit of not having to
bother with the concept of authentication backends, not to mention being
much more future-proof in case some new logic appears in auth.login.
Finally, the session DB backend seems to go out of its way to ensure a
32-character base-36 session key is unique. That’s about 160 bits, same
length as SHA-1 output! If everyone in the world started generating a key
each millisecond, with 99.999995% probability no-one would have a
collision within a million years. Just generate a random key and store the
record in process_response, which gives the option of not storing it at
all in case no data got written to the session (currently a write request
is always performed on first access, even if that’s read access).
As for how common the issue is — it’s primarily a performance issue.
Django, being the core library that it is, should have as high performance
as possible out of the box, and removing unnecessary DB write queries that
it currently issues in its default configuration (the other culprit is
update_last_login) should be high on the list.
--
Ticket URL: <https://code.djangoproject.com/ticket/25392#comment:5>
Django <https://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 unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/065.c4789d5742c39b76686e4258950ed2e1%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
