Page MenuHomeSoftware Heritage

Do not cache requests for authenticated users
AbandonedPublic

Authored by anlambert on Mar 5 2020, 9:27 PM.

Details

Reviewers
vlorentz
Group Reviewers
Reviewers
Summary

When using Django per site caching in production, requests are cached regardless
if an user is authenticated. This causes HTML view refresh issues as cached pages
can be served once a user is logged in, possibly hiding the display of its username
and the link to logout or specific interfaces reserved to authenticated users.

Depends on D2747

Diff Detail

Repository
rDWAPPS Web applications
Branch
auth-user-no-per-site-caching
Lint
No Linters Available
Unit
No Unit Test Coverage
Build Status
Buildable 10941
Build 16465: Cypress tests for swh-web diffsJenkins
Build 16464: tox-on-jenkinsJenkins
Build 16463: arc lint + arc unit

Event Timeline

Can't you do it just with this?

MIDDLEWARE += ['swh.web.common.middlewares.HtmlMinifyMiddleware',
               'django.contrib.sessions.middleware.SessionMiddleware',
               'django.middleware.cache.FetchFromCacheMiddleware']

According to https://docs.djangoproject.com/en/dev/topics/cache/#order-of-middleware , SessionMiddleware adds cookies to the Vary header, which should be taken into account by UpdateCacheMiddleware (and also by Varnish if it doesn't already)

Just tested the middlewares reordering approach but it still does not work as expected, pages are still served from cache after login.

This is clearly related to using a custom authentication backend because when using the default django one backed by a SQLite database,
the cache is correctly invalidated and HTML views are updated. I read a lot of django internal code today but I still do not get what causes
that issue.

I would be tempted to remove this per site caching feature from Django as we already have a Varnish cache in production.

Did you try calling [[https://docs.djangoproject.com/en/3.0/topics/http/sessions/#django.contrib.sessions.backends.base.SessionBase.cycle_key | request.session.cycle_key() ]] in the auth backend?

It changes the session key, which changes the cookie, so it prevents reusing the same cache thanks to Vary.

This revision now requires changes to proceed.Mar 10 2020, 3:07 PM

Did you try calling [[https://docs.djangoproject.com/en/3.0/topics/http/sessions/#django.contrib.sessions.backends.base.SessionBase.cycle_key | request.session.cycle_key() ]] in the auth backend?

It changes the session key, which changes the cookie, so it prevents reusing the same cache thanks to Vary.

request.session.cycle_key() is already applied when calling django.contrib.auth.login in the oidc-login-complete view (I double checked by tracing the executed Django internal code).

I need to dig a little further on this as I am convinced the observed cache issue can be resolved without the hack in that diff.

Abandoning this as I could not reproduce the observed cache issue once the cookies associated to my development version of swh-web have been removed.

To summarize, I got mistaken by my browsers cache.