Before I use the design as I mention above, I had thought of using two type of profile.
Russell Keith-Magee於 2015年1月28日星期三 UTC+8下午8時27分31秒寫道:
-- Using two profile model in a project, I need to implement two login page for each type of user, and I also need to check which of user is logging in.
I need to implement a custom login_required decorator to protect views, maybe called staff_required and normal_user_required.
I need to specify two LOGIN_URL for both type of users.
What is the good way to tell which type of user is logging in? Add a type field to User model?
Is it good to put staff user and regular user's username and password in same database and same table?
P.S I am a newbie. I ask many question, because I want to know what is the best practice for production level project. What are pros and cons of these different implementation.
Russell Keith-Magee於 2015年1月28日星期三 UTC+8下午8時27分31秒寫道:
On Wed, Jan 28, 2015 at 3:00 PM, 詹上潁 <boy8...@gmail.com> wrote:My project need an admin for staff and a normal website for normal user. Staff can only login to staffsite and normal user can only login to website. Staff will login to admin to do some management. They can view normal user list and detail and create or delete normal user admin. The two type of user is very different, so I want to write a model for each of them, instead of using is_staff flag. But in a project, I can only have a USER_AUTH_MODEL. Is there a good way to implement these requirements?Since a project can only have a USER_AUTH_MODEL, I separate the two type of user in two project (staffsite and website).My currently design and implementation is as follow:I wrote a standalone django app called member, and implement Member modelclass Member(AbstractBaseUser):#member related fieldsthen I create two project "staffsite" and "website". "staffsite" is for internal use, "website" is open for normal user. "staffsite" just use the django built in auth.User. Member model in "staffsite" is just a normal model. "website" use Member model as USER_AUTH_MODEL.I have two database, one for "staffsite" and one for "website". Since "staffsite" need to access Member's data, so I implement a db router for "staffsite". Whenever I need to access Member's data in"staffsite", router will route me to the correct db (You can say that I use db to link "staffsite" and "website" together.)member app need to install in both "staffsite" and "website", so I will have two copy of member app. This is not good for maintenance. Whenever I change the code in member app, I need to copy and paste to another one. I extract member app and create a standalone app, and after that I can use pip install -e to install member app for both project and I only have to keep one copy of code.This design is work, but I want to know whether there is a better way to meet the requirements.Yes, this approach will work. It might be the best approach if you really do have 2 completely different sites (even different URLs) that share a little bit of data.However, if you've got a single site that just has 2 different types of users, an approach that might be easier to manage is write a common "user" model, and then have different profiles for Admin and Normal users.This captures the idea that a User isn't something that contains specialised information - it's purely a container to hold a username and password. Once a user has logged in, if there is specialist information needed, then you put that information onto a profile model that has a foreign key to the user model.Think of it this way - regardless of whether someone is an staff member or a normal user, they're still a person. The User model should be capturing the fact that they're a person; then, you build other data models to store information about their other roles.The added advantage of this approach is that a single User can be both an Staff member and a Regular user, as needed - because they have a single User, but 2 different profiles.I hope this helps.YoursRuss Magee %-)
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 post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/ac4c80e0-ac0d-4217-bf34-9bc97b61069b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
No comments:
Post a Comment