Opened 16 years ago
Last modified 14 years ago
#8325 closed
User Authentication Tutorial has incorrect redirect_field_name value — at Version 6
Reported by: | Owned by: | nobody | |
---|---|---|---|
Component: | Documentation | Version: | dev |
Severity: | Keywords: | ||
Cc: | Triage Stage: | Accepted | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description (last modified by )
http://www.djangoproject.com/documentation/authentication/
It would be nice to update the text "redirect_field_name='redirect_to'" to "redirect_field_name='next'" in describing the login_required decorator. Using 'redirect_to' instead of 'next' causes the login user to be redirected to accounts/profile, which is confusing to a newbie like me.
Thanks!
Robert
Change History (6)
comment:1 by , 16 years ago
comment:2 by , 16 years ago
milestone: | 1.0 beta |
---|
comment:3 by , 16 years ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
comment:4 by , 16 years ago
Yes, you are correct. I more careful reading of the text would have cleared up the matter. However, I believe people are more likely to simply copy and past sample code and then tweak it to learn. As such, the "redirect_to" value in the example is meant to represent a value that the use can update to reflect a specific view. Thus, it should be shown as such: redirect_field_name='<redirect_to>' (with redirct_to in italics.) If that was the case, the angle brackets and italics say "Hey, put in your own value here!"
As a newbie with both Python and Django, I was confused and a bit frustrated. I feel that by making this small change, it would help other people like myself: Java dev's that want a web framework without the hassles of Spring or the religious fervor of Ruby on Rails.
Thank you for looking into the matter,
Robert
comment:5 by , 14 years ago
Resolution: | invalid |
---|---|
Status: | closed → reopened |
I believe request is correct, login function passes to template parameter called redirect_field_name and I believe intention for this parameter is to use one like <form ...... action=....?{{redirect_field_name}}=abc>.
In current version redirect_field_name is returned as redirect_to where redirect_to is value not name of variable so it's useless.
comment:6 by , 14 years ago
Description: | modified (diff) |
---|---|
Triage Stage: | Unreviewed → Accepted |
In response to the anonymous re-opener: you are misunderstanding the purpose here. Let me explain:
The login view is designed to be as customizable as possible. When the default values are left alone, everything works as it should: the standard login template is used, and the template is passed a context variable called "next" with the value of redirect_to
.
When you start customizing things, redirect_field_name
and redirect_to
form the key and value (respectively) that get passed to the context. It's only useless if you forget to customize the template as well so that it knows to use your customized redirect_field_name
instead of the default "next".
However, after some of the recent changes to that doc, I will agree that it needs just a few minor tweaks to be clearer on these points. I will fix it presently.
I don't understand the problem you're trying to report here. That isn't a tutorial, it's an example of how to configure the parameter in the GET request for the redirect. It's not intended to do anything unless you've go a particular view set up for handling the redirect specifically.
Creating an example that changes nothing is not a very useful example and "next" is the default value. It's the one string you will never set that parameter to be. I think we can leave this as is. The purpose of the
redirect_field_name
parameter is described immediately after the example.