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 <
graham.dumple...@gmail.com> wrote:
>
>
> 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-commentsection,
> > > 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
> >
> >
> >
> > > On Jul 7, 2010, at 3:12 AM, Jacob Fenwick wrote:
> >
> > > > 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?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django-us...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com<django-users%2bunsubscr...@googlegroups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
>
>
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
