Re: mod_wsgi using a subpath in combination with a middleware that calls django.core.urlresolvers.resolve is not working

Op donderdag 29 november 2012 09:07:01 UTC+1 schreef Jan Murre het volgende:

Op maandag 26 november 2012 19:50:50 UTC+1 schreef ke1g het volgende:

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

Hi Bill,

Thanx for your help. Using process_view is not helping in this case. Alhough I can introspect the view function, I cannot get hold of "app_name". For that I really need 'reverse'. And the reverse call is causing all the trouble (only when using mod_wsgi on a subpath).

I suspect the fact that in 'django.core.urlresolvers' the prefix is stored in a module level variable, but it is hard to pinpoint it, because mod_wsgi and pdb debugging are not working well together (although it is possible).

Regards, Jan

 
Ok, found it. It turns out that the call to resolve() was already throwing the 404. When the prefix is stripped off of the "request.path" before calling "resolve", the middleware works OK.

Regards, Jan


 

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/django-users/-/5QRoinUR5CEJ.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to django-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.