I've got a particular case that I wonder if it is worth submitting a patch for... 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 received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~--- |
On 12/21/06, Rob Hudson <[hidden email]> wrote: > > I've got a particular case that I wonder if it is worth submitting a > patch for... > > 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/. 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 [hidden email] --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~--- |
I have the same kind of setup -- no profile stuff, some views that require login and rediret as appropriate, plus a direct login link on pages whenever the user isn't logged in. To get users who click on one of those links redirected to the site root, I just have this in my login template: <input type="hidden" name="next" value="{% if next %}{{ next }}{% else %}/{% endif %}" /> This seems to do what you are looking for? Karen --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~--- |
Karen wrote: > <input type="hidden" name="next" value="{% if next %}{{ next }}{% else > %}/{% endif %}" /> That would certainly do the trick, and is easy enough. Thanks, Rob --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~--- |
I ran into another spot where not having my login at /accounts/login made things difficult... 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. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~--- |
On 22-Dec-06, at 8:26 PM, Rob Hudson wrote: > 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/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~--- |
Kenneth Gonsalves wrote: >> 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. 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...) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~--- |
Free forum by Nabble | Edit this page |