Wednesday, January 28, 2015

Re: Two user model problem


On Thu, Jan 29, 2015 at 1:39 AM, 詹上潁 <boy801213@gmail.com> wrote:
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.

No matter what approach you use, you're going to need to do this.
 
I need to specify two LOGIN_URL for both type of users.

Not necessarily - after all, logging in a *user* doesn't require you to know whether someone is an admin or not. It's only where you redirect after they log in that might be affected. So, you could have a single LOGIN_URL; LOGIN_REDIRECT_URL could then be a page that does another redirection, based on whether the user is an admin or regular user.
 
What is the good way to tell which type of user is logging in? Add a type field to User model?

You *could* add a user-type field to the base user model; alternatively, you can just query for the existence of an admin profile. Assuming you use a 1-1 field for the profile, this would mean code something like::

    user = User.objects.get(username=username)
    try:
        admin_profile = user.admin_profile
        # user is an admin user
    except AdminProfile.DoesNotExist:
        # user is not an admin user.
 
This also means you can do things like:

 * have an expiry date on admin privileges - just add extra checks for user.admin_profile once you've got it.

 * have *both* an admin profile and a user profile (for admins that also use the system as users)

Is it good to put staff user and regular user's username and password in same database and same table?
 
I can't see any reason why it would be a bad thing. 

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.

Understood - you've been asking very reasonable and detailed questions, so I'm happy to answer them :-)
 
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 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/CAJxq84884V7DWXKWvQotTs3513Y18mOK6zrDdfBbT0wWD1ZbCw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

No comments:

Post a Comment