Sure! I like your proposal, though I would like to avoid having a logout.html dedicated template, to me it feels unnecessary to take the user to an “intermedary” hop to logout.
1 Like
About that... 🙂
I do that! It's delightful.I shall get on with my bit then. 
@wsvincent Do you want to make a ticket? (Let me know if you want input on that.)
1 Like
Yes, let’s do that! I’ll get your help and make it happen next week. Thanks @nessita et al.
1 Like
Yesterday I knocked a blog post with some initial code to for a RegisterView.
I’m happy to raise a ticket for it and get a PR started if there are no major objections?
2 Likes
Ticket raised! #36006 (Add RegisterView to django.contrib.auth) – Django
1 Like
-
I think docs would be the first step here. Doc changes can also be back ported (and improve the experience for everybody). This already has an accepted ticket: #21292 (A how-to or tutorial document for using authentication views and forms is needed) – Django
-
The next step is having a login experience available out of the box, to be used as a starting point for Django users. This requires a ticket. This is how I would expect this to progress:
- A login template is created at
django/contrib/auth/templates/registration/login.html. This can use/replace the existing example: Using the Django authentication system | Django documentation | Django - As
LOGIN_REDIRECT_URL = "/accounts/profile/"by default, a very very basic profile view is created with a template which says “Hello, {{ user }}” and has the logout button
- A login template is created at
I don’t believe this ticket was created? Please correct me if I’m wrong and link it to the thread.
Signup is the most contentious. Most users will create a superuser almost immediately via the management command in order to use the admin. This means they can still benefit from the login/logout batteries. I think we need more discussion before we accept the ticket on this
1 Like
Thanks for pushing this forward Sarah!
From what I see in the Discord, so many people get into the weeds building their own views for auth and I think (I will start asking questions about this when it comes up) this might start from the fact that we don’t have a simple register view. To my mind adding one completes the battery for auth views while it doesn’t exclude the use of third-party packages or building your own one.
But docs first definitely!
hi there
+1 on having authentication on the django tutorial
i think auth is something that is needed from the beginning of someones journey in the backend world, so having it in tutorial sounds reasonable to me
also a +1 on having a register view in contrib.auth, tho i’d say we should make it simple and refrence users that need more to a 3rd-party auth package
Login is quite clear I think and works very similarly across most sites.
Registration isn’t really the case. There are a lot of things that can go wrong. And there’s no one flow that suits every site.
Which of the fields on your user model do you ask for? Only the required ones? What if there’s some constraint that makes one or another field required, but not both? Even if we stick with the standard user model, there are questions.
Do you ask for a password confirmation? Many sites these days do not. On the other hand, some sites ask to enter your email twice.
Then email confirmation, how should it work? In the ideal case you need to send the email verification directly after the user registers and not let them in the site unless they do. This way you also don’t give the user any information as to whether the email address is already in the system or not, which is a possible attack vector. However, many sites will let you register and have a look around before you verify your email, only asking you to verify your email before you make some concrete actions, to reduce friction. This is nice for the user (and the business) but then there’s no way to avoid people finding out which emails are registered. This is acceptable for some companies, but not all.
I would still like to see something done here, but it does need to be thought through. There is no one size fits all (or even one size fits most) here, and it’s not as simple as just deciding to add it.
I think the time to start thinking about this is if and when we have a better story on having the User model the standard way of doing things, discouraging custom user models, and potentially removing the non-auth stuff from the user model, which sounds quite daunting already.
Related: I wrote a long, rant-y ticket (#36204) about the lack of an example for user login/auth/etc. in the official django tutorial. The ticket was closed as a duplicate of another ticket that has been open for 11 years lol. To echo your point, and as I noted in the rant: the tutorial's including stuff like 'Customizing the admin site' before basic user login machinery seems backward.
Contrast this with Ruby on Rails (https://guides.rubyonrails.org/security.html#authentication):
"Authentication is often one of the first features implemented in a web application. It serves as the foundation for securing user data and is part of most modern web applications... Rails comes with a default authentication generator, which provides a solid starting point for securing your application by only allowing access to verified users."
I couldn't have said it better myself! Rails foregrounds this, while in Django it seems like an ugly secret hidden behind a curtain; and my suspicion is its omission from the tutorial stems from the fact that the current implementation isn't super user-friendly or easy.
The point: instead of complaining about it, I was going to take a crack at writing the tutorial documentation myself. However, if the codebase is about to change, maybe it's a moot point? Question: should I proceed or hold off?
2 Likes