[Fixed]-Django: WSGIRequest' object has no attribute 'user' on some pages?

Ran into the same issue recently, and found that it happened when a url is being accessed without the trailing slash, and the APPEND_SLASH setting is set to true:

Django processes initial request

• CommonMiddleware.process_request
  • Redirects to newurl, which has the trailing slash
• process_response is still run in custom middleware
  • request.user is not present
• HTTP 301

Django then processes the request of url with trailing slash

• process_response is run in custom middleware
  • request.user is now present

Anyone knows why some of the main attributes (user and session) are not accessible in process_response after a permanent redirect?

So it has to do with APPEND_SLASH being applied with via a redirect by Django Common Middleware, preventing the process_request() in AuthenticationMiddleware (which adds the user attribute) from being run but your process_response still being run.

Here’s how Django Process Middleware ACTUALLY Works (from django/core/handlers/base.py in Django 1.6)

1. You request a URL that does not have a trailing slash. So yourdomain.com/view. This starts the middleware flow.
2. Once the request reaches CommonMiddleware, the middleware sees that there is not a slash and returns a http.HttpResponsePermanentRedirect(newurl). This immediately stops any additional process_requests from being run, including one in AuthenticationMiddleware that add the user attribute to request
3. Because CommonMiddleware did not return an exception (including Http404), django will now take the response from the middleware and run it through EVERY process_response() in EVERY middleware listed in MIDDLEWARE_CLASSES, no matter if that middleware’s process_request() had a chance to run.

The only real way to fix this is to either move your code into a process_request() method located after AuthenticationMiddleware in MIDDLEWARE_CLASSES or detect via hasattr() if the request object has a user attribute.

do you have active this middleware?:

'django.contrib.auth.middleware.AuthenticationMiddleware'

And this middleware run before your middleware?

I had a similar issue, some of my pages dont have the user in the request so in my middleware I do a quick check

if not hasattr(request, 'user'):
    return response

There could be an exception raised within some middleware or any other code that runs before the django’s AuthenticationMiddleware (which is responsible for assigning the .user to request object).

Then there will be an AttributeError upon accessing the .user variable.

For example, any exception triggered before the AuthenticationMiddleware had a chance to run might cause the error view to execute. You’ll get the error as mentioned in the title of the question, if the error view depends on request.user.