CODEWITHSUNDEEP
pythondjangosessioncookies
Ofirov
Ofirov

Reputation: 773

Django session cookie lost because of multiple concurrent requests

I'm building an application in which the client pings the server every now and then (let's not get into why). When the server handles these requests, it checks whether the client is logged in or not using request.user.is_authenticated()

It looks something like this:

def handle_ping_request(request):
    if request.user.is_authenticated():
       # Do something...
    else:
       # Do Something else...

I've noticed that sometimes the server receives a log-in request immediately followed by a ping request (from the same user). The client is then successfully logged-in, the response returns with a new session ID (of the logged in user) and (I guess that) the old session-ID (of the anonymous user) is removed. When the ping request is processed, its request contains the old session-ID. Thus the ping request returns with a third session ID and on the next request the client makes, the client is no longer logged in.

My log-in code looks something like:

if not request.user.is_authenticated():
    user = auth.authenticate(...credentials...)

    if user and user.is_active:
        auth.login(request, user)

Do you have any suggestions on how to avoid this problem? Preferably without involving the client.

Thanks.

Upvotes: 2

Views: 2190

Answers (2)

Steve Jalim
Steve Jalim

Reputation: 12195

You could create an alternative to the standard contrib.auth.login method that keeps the same session id, rather than generating a new one, either by using a custom authentication backend that doesn't generate a new key, or by creating a custom session backend that overrides the cycle_key() method in contrib.sessions.base to reuse the same key.

BUT: think about what you might be opening yourself up to by reusing the same session key - depending on where this system is in use, you'd be making yourself more open to session hijacking (ie: there's only one session id to sniff), as well as potentially issues where caches may return the unauth page content instead of the auth page content because the sessionid is technically the same and the cache can't tell the difference between the two situations, etc, etc, etc.

In short: there's a reason it's built to work, by default, the way it does.

Upvotes: 0

Cloud Artisans
Cloud Artisans

Reputation: 4136

It's probably too messy to handle this on the server because you'll have to create some kind of a semaphore system that will also try to guess if any ping is currently from a client that is also being authenticated. My suggestion would be simply to change the client code not to ping while it's waiting for a response to its login request.

Upvotes: 1

Related Questions