I'm using a middleware to get the currently logged in user in my views and models. This helps me to for example return only the objects created or assigned to the logged-in user. Please follow this link to see which middleware that I use.

I call this middleware with:

get_current_user()

This worked fine till now. But now I experienced some strange behaviour and only for one special use-case.

I'm using this get_current_user() in a custom manager to return only projects for which the currently logged in user is a member. Membership is defined through the model "ProjectMembership". This model looks like this:

I added print "current user is" + str(get_current_user()) in order to debug it.
This print statement always! prints out the currently logged in user. When I created this function the server (manage.py runserver) was running and I did not restarted the server and the method runs as I would have expected.

But if I restart the server with manage.py runserver the UserProjectManager() crashes with this error:

Interestingly enough is that when I let the server running (after the error was thrown) and then change something in my source-code (add a sign and remove it) and save it (somewhere in my project, it does not matter where!!), click again on the link that has thrown the error, it works! More interesting is that the

print "current user is" + str(get_current_user())

in front of the line that throws the error, always returns the logged-in user correctly!

This does not make a lot of sense to me. Especially since it works if I just resave ( which leads to an automatic restart of the server!) my source.

I'm 100% sure that the error is created in the above outlined source line, since I changed this:

and then it works perfectly fine. I just say this since the above posted error is maybe a bid misleading.

Probably tough to help me out here. Would appreciate any help!

Edit:

The first answer below from "whrde" stated that the middleware approach is probably a bad idea, whereas the people in the other thread link said that the approach is fine.

Therefore I wanted to state another example where such a middleware is really convenient to use. I use it all over my application. I would just be interested if I really should remove this middleware from my app. since probably I will get more errors than the one that I posted or that the approach is fine. For example overwriting the save method for a model and setting the current_user is really easy in using this middleware. It saves me to write the same three lines in each view afer save().

Edit: Conclusio: Do not use the get_current_user() middleware since there is absolutely no need to use it. Pass the request object to your forms, object managers, overwritten object save methods etc.. and everything will be fine ;-)

I do stuff like this all time. It is a much simpler and more explicit approach than messing around with middleware and thread local storage.
–
Brian NealJan 18 '10 at 17:20

Ok, that looks like a neat approach. Thank you. I will implement it this way. It would have been great if somebody told me this a few weeks before ;-) I will leave the question as unanswered for some days, since I really want to know why this behaviour occurs.
–
Thomas KremmelJan 18 '10 at 18:36

Actually please see the edit of my question. Do you think using this kind of middleware in an overwritten model save() method is also not a good idea?
–
Thomas KremmelJan 18 '10 at 18:46

If you're only using django's admin, you can overload the ModelAdmin.save_model(self, request, obj, form, change) method, setting the obj.user = request.user before saving. Note that Django's approach here is not to use thread local (see eg b-list.org/weblog/2008/dec/24/admin) You're free to use the threadlocal hack if you like, but there's a strong argument against it. It's not necessary. Passing the user object is more flexible, explicit, readable and less complicated than a threadlocal hack, and you're free to write methods and functions to make it easier/convenient.
–
Will HardyJan 18 '10 at 20:28

1

@Tom Tom it does work. You'll need to post your code or ask another question to get more help.
–
Brian NealJan 18 '10 at 22:07

Ignoring the thread local sideshow, your problem is probably related to the fact that the AnonymousUser object is not really a User model instance. Querying the database with this object may not get you very far. You will want to check for authenticated users at some point, either in the view:

if request.user.is_authenticated():
Project.objects.for_user(request.user)

That's not the problem, since I use the @login_required decorator and the view where the problem occurs can only be called if the user is logged in. And as I said, the print "current user is" + str(get_current_user()) does return the logged in user, which is really strange.
–
Thomas KremmelJan 18 '10 at 21:26