I do not have an /accounts/profile/ URL and for the site I'm building
it doesn't make sense to have a profile page. But I do need
login/logout functionality and am using django.contrib.auth. I'm also
providing "Login" and "Logout" links in the navigation of the site.
When the user clicks on a URL who's view is decorated by
login_required, they get sent to the login page and the hidden "next"
form field is populated correctly. No problems here.
But, if they click on the login link directly, "next" is empty, and so
it defaults to /accounts/profile/.
What I'd like to do is create a patch that allows one to specify the
default redirect_to field when next is empty so I can override the
/accounts/profile/ setting.
Usage would look something like this in the urls.py:
(r'^login/$', 'django.contrib.auth.views.login', \
{'template_name': 'account/login.html', \
'default_redirect_to': '/'}),
Worthwhile?
In the meantime, I can set up a redirect from /accounts/profile/ to /,
but this seems hackish to me.
Cheers!
Rob
You can always populate "next" yourself in your template. The
resulting url would look something like this:
<a href="/login/?next=/url/to/this/page/">Login</a>
That way, when a user directly clicks the login link, they will be
directed back to that same page after logging in. Of course, that
won't help when someone directly types the address of the login page
into their address bar.
>
> What I'd like to do is create a patch that allows one to specify the
> default redirect_to field when next is empty so I can override the
> /accounts/profile/ setting.
>
> Usage would look something like this in the urls.py:
>
> (r'^login/$', 'django.contrib.auth.views.login', \
> {'template_name': 'account/login.html', \
> 'default_redirect_to': '/'}),
>
> Worthwhile?
I think so.
>
> In the meantime, I can set up a redirect from /accounts/profile/ to /,
> but this seems hackish to me.
>
> Cheers!
> Rob
>
>
> >
>
--
----
Waylan Limberg
way...@gmail.com
<input type="hidden" name="next" value="{% if next %}{{ next }}{% else
%}/{% endif %}" />
This seems to do what you are looking for?
Karen
That would certainly do the trick, and is easy enough.
Thanks,
Rob
I'm using the password reset functionality. When the user enters their
email and they get sent a password it is including a link to the
password change form. When the user isn't yet logged in,
password_change has a login_require decorator which redirects to
/accounts/login/.
I did create my own login decorator for this site for my own views that
are using it. But to use my decorator for the password views would
mean duplicating (or copying) all that code.
Are there any tricks one can do? Maybe tell my application that
password_change = django.contrib.auth.views.password_change and use my
own decorator? (Just now thought of that.)
It's certainly not a big deal to make my URLs better match what Django
expects. But at the outset, I assumed it would be easier.
> I did create my own login decorator for this site for my own views
> that
> are using it. But to use my decorator for the password views would
> mean duplicating (or copying) all that code.
use user_passes_test - it allows you to specify the url you want.
--
regards
kg
http://lawgon.livejournal.com
http://nrcfosshelpline.in/web/
Yes, that's what I'm doing in my own login decorator. The problem is
that if I want to take advantage of django.contrib.auth.views'
change_password method, which already has a decorator, I'm stuck.
I'm not at work and can't easily test this, but I wonder if this would
work...
# urls.py
r('/account/password_change/', \
'mywebsite.profile.views.password_change', \
{'template_name': 'account/pwchange.html'}),
# mywebsite.profile.views.py
password_change = \
login_required(django.contrib.auth.views.password_change)
... where login_required is my own custom decorator that uses
"user_passes_test" and redirects to /login/ instead of /accounts/login/.
I'd have to look at the code, but I think the problem would be the
password_change method is already decorated, and this would decorate it
twice.
-Rob
(This should probably on django-users at this point, my apologies for
perpetuating it here...)