Open zvolsky opened 1 year ago
I have not tested it but I think if we will allow duplicate emails, not only Activation (with possible solution above), but more actions will have problem. So probably a better approach would be to disable duplicate emails. Soemthing as is described here. https://stackoverflow.com/questions/55969952/how-can-i-avoid-a-user-from-registering-an-already-used-email-in-django. Maybe this can be applied without Djoser's change, if we would inherit UserViewSet and add email validation for User Create.
.. if so, this can be closed; but I let it open, because I am curious for meaning of others.
Thanks for creating the ticket, you're right. PRs welcome!
I have found some time to have a look into that. This integrity check should be implemented in the DB with a unique constraint.
If such index existed, the create serializer will prevent from creating a duplicate user.
But I agree, this could be a useful feature in Djoser as well.
I closed the PR above as we can't justify an additional query to the DB to meet the criteria of a few. I will leave this ticket open. If someone else has a better idea, let me know.
Depending on the project setup and requirements, it may or may not be a bug.
I think 2+ users can share same e-mail address. However when 2+ users with same address are inactive, djoser will fail so there is no possibility to activate such users. (And this is danger, because the user can try add next usernames to make the account with such email working.)
As you can see, only Django, Rest_framework & Djoser are in the traceback, so I think Djoser should be fixed.
The problem is in the
serializers.py
,class UserFunctionsMixin
,def get_user()
where the orm callUser._default_manager.get()
is handled forUser.DoesNotExist
but not forUser.MultipleObjectsReturned
.I think instead of
.get()
we could use.filter().first()
here (with appropriate removal of try/except). This would make the user activating possible, the 1st one first, then the next..Of course the users identification by email and not by username is not good here. However I think such solution could give some improvement still.
The other question, which I am not able to answer now, is: Is it possible to fix it in this way for all scenarios where
UserFunctionsMixin
is used?