How can I give access for the admin views to normal users in django?
Go to the admin site and edit the user. Check the check box (under permissions) where it says:
"Staff status
Designates whether the user can log into this admin site."
You then need to grant them appropriate permissions for them to actually see things in the admin site. That is done just below this checkbox. If you want them to be able to do everything, check the "superuser" checkbox.
Is this what you mean?
Update
The OP actually wants to apply these permissions to a group of users. To do this, go to the admin site > Auth > Groups. Create a new group. Give it the permissions you want the group of users to have. You then need to go to each user and add them to this group. They will also need to be given "staff status" in order to log in to the admin site.
Is that what you are after?
Related
I am building an intranet site for my organization with Wagtail and we are in the process of adding a knowledge base. The entire site needs to be restricted to logged-in users, but certain pages need to only be accessible to users in certain groups. For instance, only members of the IT group should be able to access the pages underneath the IT Knowledge Base page.
Currently if I set the top-level page to be accessible only by logged-in users, that permission is applied to every page on the site, and I am barred from setting more specific permissions on any child page. It is imperative that I be able to set more specific permissions on child pages.
I was able to find Wagtail Bug #4277 which seems to indicate that the logic for more specific permissions is implemented but not exposed in the admin UI.
I am not familiar with the inner workings of Wagtail yet, especially how Wagtail permissions intersect with Django permissions. How can I add more specific permissions to child pages?
You can restrict or allow users to view a site. You can also restrict or allow users to do some actions (maybe modifying an article).
To pass these restrictions or allowances django uses groups and permissions. Basically it all is based on permissions but sometimes you want to pass the permission to an entire group rather than passing permissions to users explicitly.
Therefore you could create your it_group. Then you would add the permission, let's call it it_permission to that group. When you then add a user to that group, that user then has all the group permissions. As said you don't need to organize these steps with groups. You could also add a permission, let's call it admin_status to a user directly.
When you build your views there are multiple operators that check for permissions of currently logged in user.
You could decorate your view with the permission-required-operator.
See the example:
from django.contrib.auth.decorators import permission_required
#permission_required('your_user_app.it_permission')
def my_view(request):
# only users with permissions can view this view.
Django and Wagtail are both awful at object authorisation.
For your case, it depends how tight you want to make the security, and how complex the authorization model is.
You can set permissions on a per page basis via the group edit page in the admin menu, any page below will inherit those permissions. The problem with this is that the least restrictive permissions apply and there is no deny option. If they have edit permission on a parent page, they'll have edit permission on the child page.
If you just want a superficial prevention to stop unauthorised people editing all knowledge base pages, you might look at using hooks to assess the permissions of the logged in user.
You can use before_edit_page to check before the page form is rendered for editing and redirect to a notification page if they fail, or use after_page_edit to prevent saving (not very friendly after the editor has spent some time on the page).
For before edit, for a simple one-off case and where there is a class for the KB page, where you want to allow only members of the IT Department and Site Managers groups to have access, it could be something like:
# wagtail_hooks.py
from django.contrib import messages
from django.http import HttpResponseRedirect
from wagtail import hooks
from kb.models import KnowledgeBasePage
#hooks.register("before_create_page")
#hooks.register("before_delete_page")
#hooks.register("before_edit_page")
def check_kb_permissions(request, page, page_class=None):
if (page_class or page.specific_class) == KnowledgeBasePage:
if not request.user.groups.get_queryset().filter(name__in=['Site Managers','IT Department']).exists():
messages.error(
request,
'You do not have permission to add, edit or delete knowledge base articles.\
<br><span style="padding-left:2.3em;">Contact support \
to report this issue</span>'
)
return HttpResponseRedirect(request.META.get('HTTP_REFERER', '/admin/'))
If the user fails, they stay on the same page with an error message in red banner at the top of the page.
You can build this out to a more complex authorisation model, matching user groups with models and permissions if need be, rather than the hard coded example above.
This doesn't affect CRUD permissions for programmatic operations, but if your concern is just the editor interface then this works.
I'm building an app for someone, one of its function is it allowers the owner to upload blogs to the website.
So i'm wondering if i should create a page for uploading blog or just give him staff permission so he can create and upload it through django's admin panel.
I want to know if this is safe or if it will be worth it to create a front-end template for just one person to use.
It all depends on a lot of things but I will say my opinion on some scenarios:
best practices: ya for sure you have to create a full template page with decorators that allow only staff account to access just like the admin, also don't ever depend on the admin panel even if you wanted a dashboard for an admin just create customized admin template, also some developer just remove the default admin panel on deploy, or may be make the end point of the admin panel instead of '/admin' they make something like that 'SAF#saf$%OIL>$/' to hide it for security
If it works leave it : if we are talking here on simple ecommerce app ya its fine just make a staff account for the owner so he could access the admin panel its fine
if you want to add permissions to the owner account use groups and add the account you created for the admin to this group then go to groups table and add what table should users of this group have access to it's totally fine
only make a customized admin panel when you need more functionality and visualization
I am working on Django and I create my Custom Admin Panel, But I want the same functionality of permission like as Django Default admin Panel. I create functionality for the Blog model in my Dashboard, if I log in as a super-admin and I give Normal User to blog view only permission then Normal user should not access add and edit access on my dashboard, Currently normal user also can access add and edit access on the admin panel which I developed.
I added the functionality for Admin and Normal User, if a user is admin then he can access my dashboard otherwise he/she will re redirect on the homepage.
But my problem is, how I can create permission-based functionality on my dashboard, I will give permission from Django default admin panel.
Please let me guide, Does I need to create the same URL's like Django default admin panel or there is another way to solve this issue. it's a very big problem for me please give me the correct solution.
please send if you have any documentation or solution for this.
I have a group of user called "support". I want them to be able to log in the django admin site, view and modifiy the instances of the class "HelpContextual" of the application "support".
So I created a group "support" with the permission support | help contextual | Can change help contextual. The users can log in the django admin site, but they can't see any application.
I tried to give them all the permissions of the "support" application, but still, they can't see the support app. If I use a direct link to change a "help contextual" like this one : admin/support/helpcontextual/5/change/, I get a 403.
I feel like I'm missing something obvious... Can you point it to me ?
Make sure you have done the following steps.
Add group `Support.
Under available permissions select support | help contextual | Can change help contextual from Available Permissions and then make sure you have clicked on the arrow pointing to Change Permissions. This will move the specific permission to Change Permissions.
Click Save.
Create or open users.
Select Active and Staff Users.
Select Support from Available Groups and click the arrow pointing to Chosen Groups. This will move the Support group to Chosen Group.
Don't make any change to User Permissions unless you want to grant additional permissions to any specific user.
Click save.
Have the user logout and log back in.
Answered here https://stackoverflow.com/a/7021995/626748
I had a custom backend and removed the default django authentication backend...
First, sorry for my poor english.
I'm trying to make a Django system that supports different admins to get the same admin panel, but showing them different objects, that belong to the same CustomModel.
Example:
First step: --> Login
Seconds step: --> Redirect to admin panel (django.contrib.admin.site)
and.. nothing else.
The problem is that I don't know how to show in that panel the objects that corresponds to the logged admin.
Thanks! Gracias!
This is where Django Permissions enter the picture
Django comes with a simple permissions system. It provides a way to
assign permissions to specific users and groups of users.
It’s used by the Django admin site, but you’re welcome to use it in
your own code.
The Django admin site uses permissions as follows:
Access to view the “add” form and add an object is limited to users
with the “add” permission for that type of object. Access to view the
change list, view the “change” form and change an object is limited to
users with the “change” permission for that type of object. Access to
delete an object is limited to users with the “delete” permission for
that type of object.
If you give a staff user permissions to work with only a certain type of object, that's all that he will see in the admin area.
If you have lots of different admin, you can put them into groups and grant permissions for the groups.