19

I want to set a cookie if user is logged in or not.

My middleware:

class UserStatus(object):
    def process_response(self,request,response):
        user_status = 1 if request.user.is_authenticated() else 0
        max_age = (20)*52*7*24*60*60 # 20 years (After expiry, cookie gets deleted)
        response.set_cookie(user_status_cookie,user_status,max_age)
        return response

Added to MIDDLEWARE_CLASSES in settings.py at the end.

Problem:

  • Error: 'WSGIRequest' object has no attribute 'user'
  • Why, when I have the Authentication and the Session middlewares active already ?
  • Also, some pages are working smooth where as some are giving this error.
  • What am I doing wrong ?
halfer
  • 19,824
  • 17
  • 99
  • 186
Yugal Jindle
  • 44,057
  • 43
  • 129
  • 197

6 Answers6

25

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?

YacineAzmi
  • 873
  • 1
  • 9
  • 10
  • Regarding why: It's because CommonMiddleware returned an `HttpResponse` value before `AuthenticationMiddleware.process_request` had a chance to run, which preempts `AuthenticationMiddleware`. "If it returns an HttpResponse object, Django won’t bother calling any other request, view or exception middleware, or the appropriate view; it’ll apply response middleware to that HttpResponse, and return the result." —https://docs.djangoproject.com/en/1.7/topics/http/middleware/#process-request – CJ Gaconnet Oct 16 '14 at 15:21
17

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.

NickCatal
  • 718
  • 7
  • 16
  • 3
    This is great! My app worked once I put the middleware in this order: ('django.contrib.auth.middleware.AuthenticationMiddleware', 'MyMiddleware', 'django.middleware.common.CommonMiddleware') – Temuz Mar 05 '14 at 05:00
12

According to the FineManual:

During the response phases (process_response() and process_exception() middleware), the classes are applied in reverse order, from the bottom up

So I'd say you'd better add your middleware before the auth and session middlewares (assuming it only processes the response).

This being said, I'm a bit puzzled by the fact that you only have the error on some pages ???

bruno desthuilliers
  • 75,974
  • 6
  • 88
  • 118
9

do you have active this middleware?:

'django.contrib.auth.middleware.AuthenticationMiddleware'

And this middleware run before your middleware?

Goin
  • 3,856
  • 26
  • 44
4

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
sidarcy
  • 2,958
  • 2
  • 36
  • 37
0

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.

Evgeny
  • 10,698
  • 9
  • 60
  • 70