Redirection to login screen goes to Apache root in non-root mod_wsgi based Django app

[Jacob Fenwick]

I'm deploying my Django app on Apache using mod_wsgi.

The app is using a non-root mount point.

So instead of accessing it as:

http://server.com/

I access it as:

http://server.com/myapp/

When I navigate to a url that requires logging in, I get redirected, but my mount point is dropped, e.g.:

http://server.com/accounts/login/?next=/articledist/publish/

But I should be redirected to:

http://server.com/myapp/accounts/login/?next=/articledist/publish/

If I manually navigate to the correct url it comes up. I'm even able to login correctly.

However, this is obviously not an acceptable solution.

Why is this happening?

Jacob

[Oleg Lomaka]

Exactly for your case, you may set LOGIN_URL point to '/myapp/accounts/login/', but 'next' parameter still left inaccurate.
http://docs.djangoproject.com/en/dev/ref/settings/#login-url

For more general case, to make working not only auth urls, look at those snippets:
- http://code.google.com/p/modwsgi/wiki/IntegrationWithDjango - comment section, look around URL_PREFIX keyword;
- http://opensourcemissions.wordpress.com/2010/03/12/finally-a-working-django-non-root-url-with-mod_wsgi/

[Graham Dumpleton]

On Jul 7, 11:47 am, Oleg Lomaka <oleg.lom...@gmail.com> wrote:
> Exactly for your case, you may set LOGIN_URL point to '/myapp/accounts/login/', but 'next' parameter still left inaccurate.http://docs.djangoproject.com/en/dev/ref/settings/#login-url

As far as I am concerned, Django should be inserting SCRIPT_NAME, ie.,
the mount point, automatically in front of the default value of
LOGIN_URL and you shouldn't need to override it. In other words, it
would make sense that partial URL paths in settings.py should always
be relative to the mount point.

But then, it may never have been logically right because of mod_python
brokeness in the past with handling mount point.

It would be nice if core developer could clear this issue up.

> For more general case, to make working not only auth urls, look at those snippets:

> -http://code.google.com/p/modwsgi/wiki/IntegrationWithDjango- comment section, look around URL_PREFIX keyword;

I would not pay too much attention to that comment with URL_PREFIX
example. That is a very specialised case related, as far as I can
tell, to a totally non standard configuration using
VirtualDocumentRoot. I have never actually tried to work out what it
does and the comment should probably be deleted so it doesn't cause
confusion for the majority who should never need to fiddle stuff in a
WSGI wrapper around Django entry point.

> -http://opensourcemissions.wordpress.com/2010/03/12/finally-a-working-...

I would also be careful about using example in that post as well.
Again, normally you should never need to fiddle with SCRIPT_NAME and
PATH_INFO. If you are you are likely using Django wrong. Using the
mount point in urls.py is bad and using absolute paths in URLs rather
than special function to create them relative to mount point in
templates or code is also bad. Overall it shouldn't matter to the
application itself if under runserver it appears at root of host
rather than a sub URL.

Graham

[Jacob Fenwick]

I agree with Graham's analysis.

I've seen both the links Oleg posted and I feel like both those hacks should be unnecessary.

I ran into this same problem when I tried to submit a form.

I found out after some research that I needed to use a the url tag in my templates.

Once I replaced the absolute urls with the url tag it fixed my problem.

But now I've run into the problem all over again with the auth code.

I'm starting to think this is a bug in the Django auth code.

Should I submit this as a bug?

If not, do I need to declare an absolute url using LOGIN_URL?

Jacob

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

[Graham Dumpleton]

On Jul 7, 12:01 pm, Graham Dumpleton <graham.dumple...@gmail.com>
wrote:

> On Jul 7, 11:47 am, Oleg Lomaka <oleg.lom...@gmail.com> wrote:
>
> > Exactly for your case, you may set LOGIN_URL point to '/myapp/accounts/login/', but 'next' parameter still left inaccurate.http://docs.djangoproject.com/en/dev/ref/settings/#login-url
>
> As far as I am concerned, Django should be inserting SCRIPT_NAME, ie.,
> the mount point, automatically in front of the default value of
> LOGIN_URL and you shouldn't need to override it. In other words, it
> would make sense that partial URL paths in settings.py should always
> be relative to the mount point.
>
> But then, it may never have been logically right because of mod_python
> brokeness in the past with handling mount point.
>
> It would be nice if core developer could clear this issue up.

Oh well, looks like it doesn't do it in way that I thought would be
sane way of doing it. :-(

def logout_then_login(request, login_url=None):
"Logs out the user if he is logged in. Then redirects to the log-
in page."
if not login_url:
login_url = settings.LOGIN_URL
return logout(request, login_url)

def redirect_to_login(next, login_url=None,
redirect_field_name=REDIRECT_FIELD_NAME):
"Redirects the user to the login page, passing the given 'next'
page"
if not login_url:
login_url = settings.LOGIN_URL
return HttpResponseRedirect('%s?%s=%s' % (login_url,
urlquote(redirect_field_name), urlquote(next)))

Ie., uses raw settings value instead of putting SCRIPT_NAME in front
by the look of it.

BTW, aren't Location response headers for redirects meant to be a full
'http' or 'https' address? I know browsers will usually work if not,
but thought the standards required that they were.

Quoting wikipedia:

"""
According to the HTTP protocol, the Location header must contain an
absolute URI[5]. When redirecting from one page to another within the
same site, it is a common mistake to use a relative URI. As a result
most browsers tolerate relative URIs in the Location header, but some
browsers display a warning to the end user.
"""

Or am I confusing 'absolute' and that it doesn't have to have 'http://
host' in it?

Graham

> > For more general case, to make working not only auth urls, look at those snippets:

> > -http://code.google.com/p/modwsgi/wiki/IntegrationWithDjango-comment section, look around URL_PREFIX keyword;

[Jacob Fenwick]

Just as a followup:

http://code.djangoproject.com/ticket/8906

Looks like they will never fix this or recognize it as a bug.

I find this kind of disappointing and confusing.

If they're going to do that why not just get rid of the {% url %} tag and make people always declare their absolute URL (including mount point) in the settings file for everything so it's the same across the board?

Jacob

[Graham Dumpleton]

I posted something about it on Django developers list, so keep an eye
out for it there.

Graham

On Jul 8, 12:25 am, Jacob Fenwick <jacob.fenw...@gmail.com> wrote:
> Just as a followup:
>
> http://code.djangoproject.com/ticket/8906
>
> Looks like they will never fix this or recognize it as a bug.
>
> I find this kind of disappointing and confusing.
>
> If they're going to do that why not just get rid of the {% url %} tag and
> make people always declare their absolute URL (including mount point) in the
> settings file for everything so it's the same across the board?
>
> Jacob
>
> On Tue, Jul 6, 2010 at 10:13 PM, Graham Dumpleton <
>
>
>

> > > > -http://code.google.com/p/modwsgi/wiki/IntegrationWithDjango-commentse..., look around URL_PREFIX keyword;

> > django-users...@googlegroups.com<django-users%2Bunsubscribe@google groups.com>
> > .