I’m trying to set up a very plain user login system using as much of the Django default user model as possible. I’d like for the login/logout/ password emails to show the name of the project and very basic customization like that.
I used a namespace in my url files, and I don’t know where the world went sideways, but that seemed to require changes to just about every default .html file for user login/password reset. All that to add namespace decorators.
Then I find that the system only asks for an email for the target of the reset.
So if someone else registers an account with the same email… how does this even work?!
I’m a complete newbie to Django, so I have to ask…
(a) should I be using this default user model stuff?
(b) can anyone point me at a not-overly complex django project that sets up user-login with email-based password reset?
(c) Is there an easy alternative toward password reset that doesn’t involve email at all?
Sorry if this is very basic. I’ve been beating my head against this (with some chatGPT help) and after many hours… I’m still working on getting the password reset system to work (rather than the project that I wanted to work on).
Maybe I’m just using it all wrong?
I didn’t understand the question very well. But if you have multiple users who may have the same email address, they will probably need to provide something unique, like a username, before sending a password reset.
a) Django has already made sure that the user model has enough fields that we need to use it. See full list here
b) You can find a huge list of different Django projects on the internet. Here is one of them
c) I guess using email is the easiest, you can also use a phone number or two-step authentication.
1 Like
Also take a look at the django-allauth lib for different stage of auntification
1 Like
You get one email per account for the password reset requests. (True story - if you create a test system with 5000 user names all sharing the same email address, then request a password reset, you will get 5000 emails. Don’t ask me how I know this…)
You really don’t need or want to do this with your registration urls. It doesn’t provide you with any benefits and as you can see, it causes some pain.
It might help if you posted the specific code with one of the templates that you’re working with for us here to see whether or not this is the case.
A good rule-of-thumb with Django. Don’t change system-level items unless (a) you know it’s necessary to do so, and (b) you understand the implications of doing it. This principle has served me very well over the past 10 years of working with Django.
2 Likes
Thanks. I had added the app_name to my urlpattern file (app level) as I was following one of the prime tutorials for django. There were a series of downstream costs to that which I didn’t realize. A lot of the templated registration html files assume you haven’t done that. (at least I think that is in part the problem) After taking that out… things are working much better.
You shouldn’t have the admin in your app-level urls.py file. It should be in the root urls.py file.
See the docs and examples at Writing your first Django app, part 1 | Django documentation | Django
I’m curious, what tutorial are you following?
(You should only be using tutorial material known to be good, such as those listed on the Awesome Django page.)
I was following the example you linked. It’s the bit in here:
regarding Namespacing URL names…
I had added my registration links to the app level url file with app_name set… and that meant a world of “customization” I hadn’t intended on. Do the registration links rightly belong at the top level BTW? Maybe that’s root (ha) of the problem?
That’s the easiest way to do it, but it’s not required. They can be specified to be “deeper” in your url structure, but the url names must not be namespaced.
The issue I believe you’re encountering would be the reversal of the names to identify the url - having them namespaced would change that.
1 Like