Question

I’m using an existing database for my latest Django project, so unless I change my Models or the Django auth code, it’s going to be rather difficult to merge the two.

Rather than messing with the existing auth backend, I’m planning on just writing my own authentication app.

Anyway, all of my previous authentication apps have been written in PHP, where basically i just throw everything in session variables and verify them on every page… Here’s what I’m a bit confused about. It appears that when a user is authenticated/logged in, the entire user is added to a session, but I can’t figure out where or how that is occurring.

In the default Django login function, it’s assigning user to request.user … is this being saved as a session variable somehow or is it just passed into the next view? If it is just being passed to the next view, how are future requests authenticated without requiring further login requests?

The default Django auth login is below..

def login(request, user):
    """
    Persist a user id and a backend in the request. This way a user doesn't
    have to reauthenticate on every request.
    """
    if user is None:
        user = request.user
    # TODO: It would be nice to support different login methods, like signed cookies.
    if SESSION_KEY in request.session:
        if request.session[SESSION_KEY] != user.id:
            # To avoid reusing another user's session, create a new, empty
            # session if the existing session corresponds to a different
            # authenticated user.
            request.session.flush()
    else:
        request.session.cycle_key()
    request.session[SESSION_KEY] = user.id
    request.session[BACKEND_SESSION_KEY] = user.backend
    if hasattr(request, 'user'):
        request.user = user
    user_logged_in.send(sender=user.__class__, request=request, user=user)

I also tried to follow the user_logged_in.send(), which is in django.dispatch.dispatcher.send but I’m not entirely sure what that’s supposed to do either.

def send(self, sender, **named):
    """
    Send signal from sender to all connected receivers.

    If any receiver raises an error, the error propagates back through send,
    terminating the dispatch loop, so it is quite possible to not have all
    receivers called if a raises an error.

    Arguments:

        sender
            The sender of the signal Either a specific object or None.

        named
            Named arguments which will be passed to receivers.

    Returns a list of tuple pairs [(receiver, response), ... ].
    """
    responses = []
    if not self.receivers:
        return responses

    for receiver in self._live_receivers(_make_id(sender)):
        response = receiver(signal=self, sender=sender, **named)
        responses.append((receiver, response))
    return responses

Basically what I’m looking for is for someone to explain an efficient way to save user session data in Python that does not depend on the Django framework. A little run-through of the Django authentication would be nice as well.

Answer 1

HTTP is stateless; regardless of the server used, the framework or language, there is no intrinsic way for an HTTP client to say “this request is part of that session”. That’s part of the design of HTTP.

So sessions are always a feature of the web application; either supported by the a web app framework or implemented in the app itself. The most usual way for a stateful session to be created from the stateless protocol is with cookies; Clients will store cookies at the request of a server and return those same cookies to that server in future requests.

Session data can be serialized and stored in the cookie itself, but that’s both insecure (secret information could be forged or eavesdropped), and inefficient (takes bandwidth even though the individual bytes are of no use to the client), and so the preferred solution is to use an opaque (and even better, single use) session key is stored in a cookie, and the web application will store session data out of band; either in memory, in the filesystem, or a database backend, or some other option.

django takes care of most of this transparently in “middleware”, modules that modify incoming requests and outgoing responses. The auth middleware will read a cookie and check if that represents a logged in user, and if so, add a user object to the request; it also attaches cookies to responses when a user gets logged in. the session middlware works in a similar fashion, checking for a cookie, and reading the session data from wherever it was stored between requests, and also grabbing session data from responses and storing them, along with setting a cookie to associate the client’s session with the session data it just stored.

Since both of these features are useful, independent of each other (I tend to avoid sessions, but usually use some kind of authentication), they do not depend on each other. Session-like authentication is implemented in a similar manner as sessions, but authenticated users are not stored in “The Session”, nor are sessions attached to “The authenticated User”.

You might not think so, but django’s authentication system is designed to be extended; if you already have a database of valid users you’d like to authenticate against, it’s very simple to add a new auth backend that dovetails neatly into the standard django auth application (which means you can also use other applications that depend on it in turn).