Many e-mail systems allow you to add a suffix to the username portion of
the address, separated by something like a "-", or, last time I checked for
gmail, by a "+", and it will still be delivered to the same mailbox. For
example, I expect mail sent to
ks.kennysoh+ad...@gmail.com
will still reach you. But username match in Django probably won't treat
these the same, so you could have two accounts: custo...@email.com, and
customer-zy...@email.com which, being separate Django accounts, could have
separate passwords.
That's not ideal because there are almost certainly some email providers
who don't follow this convention, and will treat the two addresses as
different, making it impossible to get activation emails, password reset
emails, and anything else that you want the Django instance to send you.
If you are willing to crawl down inside the Django code and make changes,
you can rework user so that, for example, username isn't unique, but
username and admin flag are "unique_together" (providing that the database
that you are using supports it), in which case these can be separate
accounts. Or you could add decorations to the user field that are
impossible to type because your login code doesn't allow the separator,
which can be something not allowed in email addresses, like the nul
character, but you then also have to modify email sending to drop any such
decorator when producing the "to" part of a message.
But modifying the core code means re-applying the patch whenever you take
an update, and if things have changed in the area(s) that you modified,
recoding may be required, so changing the core code is considered fragile.
It might be (I'll let you investigate for yourself) that the supported
custom User model scheme lets you override user lookup at login in a
suitable way, decorating the username with, for example, a leading A for
admins and a leading U for normal users, but keep the undecorated email
address in a separate email field. So long as whatever method you have to
override is part of the formal custom user model mechanism, it should be
pretty stable.
Good luck
On Mon, Apr 13, 2020 at 4:17 AM Carsten Fuchs <carsten.fu...@cafu.de> wrote:
> Hello,
>
> Am 13.04.20 um 02:59 schrieb Kenny Soh:
> > * An admin account must not share the same password as the customer
> account.
>
> Your entire problem would become much easier if you just dropped that
> requirement. Whatever you want to achieve with forcing a single user to
> keep two passwords, I'm sure that you're better off with a different
> approach.
>
> Importantly, dropping this requirement gives you the option to follow the
> advice in the article that you linked (
> https://simpleisbetterthancomplex.com/tutorial/2018/01/18/how-to-implement-multiple-user-types-with-django.html
> )
>
> Best regards,
> Carsten
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/bccdd94d-2344-b1c2-0478-c4e0d47d0d51%40cafu.de
> .
>
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/CAB%2BAj0vMhTCCstNx87gtRunX_eoEJiZhQ_%2BZAcA_invnRrno2w%40mail.gmail.com.
