Django user model. 1 admin account, 1 customer account with the same email and different password

[Kenny Soh]

Im trying to handle a use case where i have 2 roles. (admin , customer)

There will be an admin portal and a customer portal (2 different login pages ).

• An admin can invite a customer
• An admin can be a customer as well , can invite himself into the customer portal
• An admin account must not share the same password as the customer account.
• Email is used as the unique field for both admin and customer account.

For example :

Admin account - cust...@email.com /password1
Customer account - cust...@email.com /password2

Solution 1: - Permission. Having 1 account with admin permission and customer permission. (This cant work to fit the business use case)

Based on this article: https://simpleisbetterthancomplex.com/tutorial/2018/01/18/how-to-implement-multiple-user-types-with-django.html

Solution 2: - Creating 2 django projects. One for each user model since both accounts cant share password. The reason for separating into 2 projects is because resources such as session,login, logout will not be shared. So each portal(admin,customer) has their own resource.

• A create Customer API to allow admin to create a customer account in customer django project.

• A shared db to share related data

This is the only way i can think of to handle the use case. Please let me know if anyone has a better idea to handle this.

[Ernest Thuku]

Option 2 seems good...I could think of it before proceeding to any other option

--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/181ec499-e36c-4009-9587-06386219ab8d%40googlegroups.com.

[Carsten Fuchs]

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

[Bill Freeman]

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.kenny...@gmail.com

will still reach you.  But username match in Django probably won't treat these the same, so you could have two accounts: cust...@email.com, and custome...@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

--
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...@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.