On Thu, Nov 22, 2012 at 11:28 AM, Jan Murre
<jan....@gmail.com> wrote:
Hi,
I have the following peculiar problem that is very easy to reproduce.
I use a simple middleware the attaches the 'app_name' that is defined in the urlconf to 'request.user' for subsequent use.
----
from django.core.urlresolvers import resolve
class ApplicationAwareMiddleware(object):
"""
Middleware class that determines the name of the application of the current
view and attaches that to the current user.
"""
def process_request(self, request):
request.user.app_name = resolve(request.path).app_name
-----
This middleware kills Django's urls resolution when used with mod_wsgi using a suppath, like:
WSGIScriptAlias /subpath <path-to>/django.wsgi
It seems that the call to 'django.core.urlresolvers.resolve' has some kind of nasty side-effect.
I tried things like delaying the call to 'resolve', but to no avail. Pointers anyone?
Regards, Jan
Are you figuring out the url resolution on your own? I would have thought that you would use process_view(), so that the view function has already been looked up, and you can just introspect it.
I'd be worried that the anonymous user shouldn't be modified. I'd add the decoration to the request, or maybe request.META, rather than the user.
It might be cleaner yet to write a decorator for your view that adds the information as an early positional argument (say, just after request) at call time. This also allows you to avoid the work for views that don't need it.
Or if you're doing this to views that are outside of your control, so that you couldn't decorate them, maybe I see why you want to put the data on the user. If so, do check that the anonymous user accepts attribute setting. And I believe that request.user is a lazy object, so try referencing, say, request.user.email before you modify the user object, to see if that makes a difference.
Bill
Bill