I've recently started learning/using django; I'm trying to figure out a way to have two separate authentications systems for administrators and users. Rather than create a whole new auth system, I'd like to leverage django's built-in functionality (i.e. session management, #login_required decorator, etc.).
Specifically, I want to have two separate login tables - one for admins, one for users. The admin login table should be the default table that django generates with its default fields (ie. id, username, email, is_staff, etc.). The user table, on the other hand, I want to have only 5 fields - id, email, password, first_name, last_name. Furthermore, I want to use django built-in session management for both login tables and the #login_required decorator for their respective views. Lastly, I want two separate and distinct login forms for admins and users.
Anyone have any suggestions on how I can achieve my goal or know of any articles/examples that could help me along?
If I understand your question correctly (and perhaps I don't), I think you're asking how to create a separate login form for non-admin users, while still using the standard Django authentication mechanisms, User model, etc. This is supported natively by Django through views in django.contrib.auth.views.
You want to start with django.contrib.auth.views.login. Add a line to your urlconf like so:
(r'^/login/$', 'django.contrib.auth.views.login', {'template_name': 'myapp/login.html'})
The login generic view accepts the template_name parameter, which is the path to your custom login template (there is a generic one you can use as well, provided by django.contrib.auth).
Full documentation on the login, logout, password_change, and other generic views are available in the Django Authentication Docs.
You could potentially write one or more custom authentication backends. This is documented here. I have written a custom backend to authenticate against an LDAP server, for example.
Modify things slightly so that users have a category prefix on their username? You haven't given us much info on what you want to do, it's possible that your needs might be met by using the sites framework, or simply two separate django installs.
If what you're trying to do is make the user login page and the admin login page separate, just use the built in framework as detailed in the docs to create a "user" login page and leave the admin one alone. If you're worried that users will somehow start editing admin login stuff, don't be, they won't unless you let them.
Related
Currently I implemented a login routine for the website I am working on, according to This Tutorial.
Also I am not authenticating the user with djangos own system, because I am using authentication against the LDAP of my company (django-auth-ldap).
Currently I am using a general user to login to the database, which has universal access to all data, which also gives full access to any user logging in to the website.
To avoid that I would like to know how I can connect to the database as the individual user, who just logged in to the website.
Thanks in advance and sorry for bad english
Restricting user access to functionality and authenticating with the DB are handled separately in Django. You might be able to read the privileges of your users from the DB and map them to Django permissions but this is non-trivial (about Permissions see https://docs.djangoproject.com/en/2.1/topics/auth/default/#permissions-and-authorization).
In a UI/UX that has functionalities restricted depending on authorization, the frontend and backend need to be aware that permissions need to be checked and missing authorization needs to be communicated in some way or other to the user.
Example:
Users in group A are allowed to delete X. They see the "delete" button and there might also be an AJAX call that can delete X.
Users in group B are not allowed to delete X. They do not see the delete button and the AJAX call that can delete X needs to check for that permission and/or user group membership.
If you are only using a DB level authorization layer than - how would you know if the "delete" button should be displayed and for what to check in the AJAX call?
hi!
If I'm getting your problem correctly, the user you are creating is a Super User every time right?
Well if you are using Django auth.User model, you can just make User_object.is_super to False and then restrict the access of users though if-else in view! (User_object is the object of the auth.User model)
Does that made any sense?
//BTW, a side-note, a mistake I made while making my first custom user model: make sure to store your passwords hashed using Django hashes and salts!
I've created a custom user model (AbstractBaseUser) so that user could login into my website.
The problem is that I want to keep using Django's default user and authentication system for the admin so that staff could easily log in and manage stuff.
I saw a lot of tutorials but all of the instruct to change the setting AUTH_USER_MODEL, but if I change that I won't be able to keep using Django's default user.
Is there any solution for this?
Thanks in advance.
I have never implemented this myself, but to point you in the right direction, it may be worth having a read through this:
https://docs.djangoproject.com/en/1.10/topics/auth/customizing/#authentication-backends
By the sounds of things you may be able to write an authentication backend for your front end user model, that you can run in tandem with Django's authentication system.
If you could get this to work, I would imagine that you would then have to make sure that the front end user model, once authenticated, can not access the admin part of the site.
For me the million dollar question here is, why do you want to keep the front end and backend users on separate models? They both have the same job, to authenticate the user?
I've created several projects in the past where there are front end users and admin users. Out of the box, without any modification you set the user attribute is_staff=False for front end users and is_staff=True for the admin users; that determines whether or not a user can access the admin part of the site, and I've never had any issues with this approach.
If the front end user (or backend user) desires additional functionality, the simplest solution would be to extend the user model:
https://docs.djangoproject.com/en/1.10/topics/auth/customizing/#extending-the-existing-user-model
Alternatively you could user your could create a custom user model and use this for both.
If you're willing to provide more details, perhaps I could help further, but unless there's a strong reason for having separate user models, I'd just stick with the one and configure and extend as you need.
I hope this helps.
I have begun to implement authentication throughout my applications in Django and have done this quite successfully with the Django login_required decorator.
However, I notice that this will always reroute to the deafault login URL: /accounts/... which is non-existent for me. I have been doing all my authentication through /admin/...
I imagine that the two are for different purposes (one for the admin users and allow access to the admin console) however, I cannot find any views for the accounts version (vs. admin). My questions are thus as follows:
What is the difference between /accounts/... and /admin/... if they use the same user models?
Are these /accounts/... views built in/templateable? How does one turn them on? Or do I need to create each manually?
Unfortunately I have found the documentation on this topic to be rather confusing and as such any help would be greatly appreciated.
If you are not logged in, Django uses the LOGIN_URL to decide which url to redirect to. By default, this is set to '/accounts/login/'.
If you use a different login url, then you should update your LOGIN_URL setting.
The disadvantage of using the Django admin to log in users, is that non-staff members will not be able to log in using the Django admin.
Django comes with authentication views, including a login view. If you want to allow non-staff members to log in, you should enable it.
The '/accounts/' is just a url that out of best practices most people when handling authentication. There are no built in templates for accounts. the '/accounts/' is just a default placed.
To change the url to fit your applications url, go to your settings.py file and you can add a LOGIN_URL variable to specify which location for the authentication to redirect to. In your case it will look like this.
LOGIN_URL = '/admin'
This will redirect all unauthenticated requests to '/admin'
Have anyone used these 2 django apps together? I want to know how well these 2 gel together along with Django's User Authentication system.
When I mean Django's User Authentication System, I mean I should be able to use decorators like #login_required or grant permission to specific views (or functions in views.py) based on who the user is.
There shouldn`t be any problems there. Django-Socialauth adda new auth backends, and it should works fine with permissions and decorators. And Django resistration just register a user on site, so unless you remove standard auth backend, it will work fine too.
I am quite new to Django, so it may be a stupid question, but, nevertheless:
I need Django admin part to edit contents on the site, and also I want to have authentification, that will allow registred users to leave comments.
I have the following idea of implementation it: have 2 different tables(admins and other registred users) and use the /admin url to login in admin area and /login to login other users for leaving comments, etc.
Is this nice scheme? Or should I use the same url for all users, that will redirect admins to admin area?? What is the most simple way to implement this?
Examples of nice Django code are highly appreciated.
Thanks!
"have 2 different tables(admins and other registred users)"
Bad idea. Django auth module has one user table. You can easily assign users to groups. Some groups have admin access to anything. Other groups can only leave comments. Read up on the auth module before you do anything more.
http://docs.djangoproject.com/en/dev/topics/auth/
"use the /admin url to login in admin area and /login to login other users for leaving comments, etc."
That's fine. Turns out, both with use the same authentication mechanism. Read this: http://docs.djangoproject.com/en/dev/topics/auth/#the-login-required-decorator
All view functions will use decorators to determine who's allowed to perform those functions.