Before I use the design as I mention above, I had thought of using two type of profile. 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, 詹上潁 <[email protected] <javascript:>> > 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 model >> >> class Member(AbstractBaseUser): >> #member related fields >> >> then 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. > > Yours > Russ 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 [email protected]. To post to this group, send email to [email protected]. 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.
