Dynamic session timeout based on user type

Using Django Forms & APIs
1

We’re looking at our session management on our project, and are exploring ways to make our platform more secure. We are exploring how to balance out the user experience with the risk of session highjacking. Shortening session duration is a good way to mitigate this risk, but past a certain point, it can degrade the user experience if e.g. users have to login too often.

Our system has -broadly speaking- 4 kind of users with more or less privileges:

  • Internal staff with access to a broad range of actions, across multiple organisations (our clients), also gets access to the Django admin.
  • Organisation admin: users in our clients org, they get more permissions like user management, etc… but are limited to the data within their org.
  • Regular users: can perform a limited set of actions, all within their orgs
  • Anonymous users: can only do a very limited set of actions, on some very specific pages

As we can see, the risk profile of each user type is different, and it would be an order of magnitude worse if a security issue happened with a session from an internal staff vs a regular user. And in terms of UX, we can afford to be more aggressive with internal users vs external ones.

We had the idea of implementing a dynamic session timeout based on the type of user: internal staff would have a timeout of something short like ~15mins, regular users could be a few hours/1 day, while anonymous users could be much longer sessions.

I looked into the current Django implementation, and from what I can see, it doesn’t seem easily feasible in the current state of things as the expiry is obtained in the SessionMiddleware:

max_age = request.session.get_expiry_age()

I was thinking to change this line to pass the request down:

max_age = request.session.get_expiry_age(request)

And then implement my own logic by subclassing Session and overriding get_session_cookie_age. However, doing so currently requires (I think) to copy the 55 lines long SessionMiddleware.process_response and change that single line.

Did I miss anything? Is there a simpler way to do what I want to do? Is there an appetite to change this request.session.get_expiry_age() line in the middleware in Django? Is there interest in making session expiry more dynamic in general?

2

<conjecture>
I wonder if you could create new middleware that examines the cookie being returned by SessionMiddleware and adjust the max_age?

Since the cookie is set in the process_response, the new middleware would need to be before SessonMiddleware such that it is called during the response after SessionMiddleware has done its work.

You would still have the request object available at that point, which should still give you access to the requesting user.
</conjecture>

1 Like
3

That would indeed make the client side session expiry work. However, we’re using the database backend, which also stores the expiry server side, and I think that would make it inconsistent.

Looking at where it’s set, that comes from the SessionStore.create_model_instance method and that uses a different method get_expiry_date, which looks similar to get_expiry_age but return a datatime.datetime instance instead of a number of seconds…

With all the sync/async variants, I’m starting to see the limits of my own proposal, as it would involve passing the request to a number of methods and would be a significant API change.

While writing this response, I realised that we can take the middleware idea one step further to adjust not only the session cookie expiry, but also the server side session.

Thanks for your help @KenWhitesell!