Using settings.LOGIN_URL and django.core.urlresolvers.reverse
Matt
I have a quick question about the new LOGIN_URL, LOGOUT_URL, and
LOGIN_REDIRECT_URL settings. If, in my project's settings module, I
write:
LOGIN_URL = '/blah/'
LOGOUT_URL = '/blah/blah/'
LOGIN_REDIRECT_URL = '/blah/blah/blah/'
They work just fine. But I want to remove hard-coded URLs from my
code; so I write:
from django.core.urlresolvers import reverse
LOGIN_URL = reverse('django.contrib.auth.views.login')
LOGOUT_URL = reverse('django.contrib.auth.views.logout')
LOGIN_REDIRECT_URL = reverse('gigall.apps.accounts.views.profile')
This fails; the URLs used are Django's defaults.
Does anyone know why this is so? And can I work around it?
Cheers,
M.
--
Matt Riggott (mailto:matt.r...@gmail.com).
Dictated but not read.
Malcolm Tredinnick
> Hi everyone,
>
> I have a quick question about the new LOGIN_URL, LOGOUT_URL, and
> LOGIN_REDIRECT_URL settings. If, in my project's settings module, I
> write:
>
> LOGIN_URL = '/blah/'
> LOGOUT_URL = '/blah/blah/'
> LOGIN_REDIRECT_URL = '/blah/blah/blah/'
>
> They work just fine. But I want to remove hard-coded URLs from my
> code; so I write:
>
> from django.core.urlresolvers import reverse
> LOGIN_URL = reverse('django.contrib.auth.views.login')
> LOGOUT_URL = reverse('django.contrib.auth.views.logout')
> LOGIN_REDIRECT_URL = reverse('gigall.apps.accounts.views.profile')
>
> This fails; the URLs used are Django's defaults.
>
> Does anyone know why this is so? And can I work around it?
I have doubts that using reverse() in the settings file is going to
work. It relies on the value of ROOT_URLCONF, which will only be
available once the settings module has been fully imported. So trying to
access that value *whilst* settings is being imported looks like it's
doomed to failure.
There are some cases where you're just going to need to put strings for
URLs. Feel free to come up with a fix, though.
Regards,
Malcolm
Matt
wrote:
> I have doubts that using reverse() in the settings file is going to
> work. It relies on the value of ROOT_URLCONF, which will only be
> available once the settings module has been fully imported. So trying to
> access that value *whilst* settings is being imported looks like it's
> doomed to failure.
>
> There are some cases where you're just going to need to put strings for
> URLs. Feel free to come up with a fix, though.
The first thing that comes to mind is to have a setting called
LOGIN_VIEW rather than LOGIN_URL. Then, rather than functions
redirecting to LOGIN_URL they call reverse(LOGIN_VIEW) instead.
To use django.contrib.auth.decorators.user_passes_test as an example:
from django.core.urlresolvers import reverse
def user_passes_test(test_func, login_url=None):
"""
Decorator for views that checks that the user passes the given
test,
redirecting to the log-in page if necessary. The test should
be a callable
that takes the user object and returns True if the user
passes.
"""
def _dec(view_func):
def _checklogin(request, *args, **kwargs):
if test_func(request.user):
return view_func(request, *args, **kwargs)
from django.conf import settings
login_url = reverse(settings.LOGIN_VIEW)
return HttpResponseRedirect('%s?%s=%s' % (login_url,
REDIRECT_FIELD_NAME, quote(request.get_full_path())))
_checklogin.__doc__ = view_func.__doc__
_checklogin.__dict__ = view_func.__dict__
return _checklogin
return _dec
(Pretty-printed code available at http://dpaste.com/hold/9032/.)
How does that look?
M.
--
Matt Riggott (mailto:matt.rigg...@gmail.com).
Dictated but not read.
