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 <[email protected]> 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 < > > > > [email protected]> wrote: > > > On Jul 7, 12:01 pm, Graham Dumpleton <[email protected]> > > wrote: > > > On Jul 7, 11:47 am, Oleg Lomaka <[email protected]> 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-commentse..., > > > > 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 [email protected]. > > To unsubscribe from this group, send email to > > [email protected]<django-users%2bunsubscr...@google > > groups.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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
