Generic CBV Permissions Helper
A permission helper that can be included in any generic CBV, it uses the model attribute of the class to load all the permissions and tests a user can perform that action before dispatching the view.
- permissions
Snippet List
CBV decorator from view function decorator
The Mixin approach for applying permissions to CBV views suffers from 3 issues: 1. you need to read the code to see what permissions are being applied to a View 2. multiple bits of disparate code required to specify, e.g., a simple permission check 3. permissions set on a base class are overridden by permission set on sub-class, unless special care is taken Here's a nice trick, using only built-in django machinery, apply a decorator intended to decorate a django view function to a CBV view. https://docs.djangoproject.com/en/1.11/topics/class-based-views/intro/#decorating-the-class This approach works for any function decorators with arguments - simply wrap it in a function that takes the same arguments: def my_cbv_decorator(*args **kwargs): return method_decorator(a_view_function_decorator(*args, **kwargs), name='dispatch') Use your new CBV decorator to decorate View sub-classes: @my_cbv_decorator('some_parameter') class MyCBView(django.views.generic.TemplateView): pass # dispatch method for this view is now wrapped by a_view_function_decorator Note: you can also pass decorator parameter directly to method_decorator, but wrapping it up like this makes the code read nicer.
- view
- decorator
- permissions
- cbv
Mixin to enable admin permissions without using PermissionsMixin and models
Implements necessary permission checks on a user model to be compatible with django admin, but just return true on all permissions without actually checking it against anything. Useful when you have a user model that should always be allowed to use django admin, and you don't care about using django's own PermissionsMixin and don't want to have those models added to your database.
- admin
- mixin
- permissions
Group permissions selection in admin filtered by your app models
Sometimes you just don't want to display every permission django has, you just want a short list showing the permissions for some of your apps (or even django core apps). GROUP_PERMISSIONS_MODELS must be a list of your app models. Dotted path (in lowercase) required, app name + model *class* name.
- admin
- group
- permissions
Aggiornare i Content Types e i Permessi del Model di una Tabella nell Admin
Script per Aggiornare i ContentTypes e i Permessi del Model di una Tabella nell Admin [Django Blog](http://www.darioagliottone.it/blog)
- models
- admin
- permissions
- users
- ContentTypes
- Permessi
Support for permissions for anonymous users in django ModelBackend
Model backend that enables permissions for AnonymusUsers. I wanted it to be as simple as possible so anonymous users just forward their permission checks to some fixed user model. This instance can be edited via django admin, assigned to groups, etc. To control which user will represent anonymous user you use ANONYMOUS_USER_NAME setting in settings file. To provide some sensible level of security i enforce following for user that represents anonymous user: * This user must have password equal to UNUSABLE_PASSWORD * This user may not log in * You cant cange password for this user via admin. You need to enable this backend by setting AUTHENTICATION_BACKENDS. Please note that you should not place this backend alongside django ModelBackend. This backend inherits from it.
- user
- auth
- permissions
- anonymous
User groups template tag
This snippet is an improved version of the [ifusergroup](http://djangosnippets.org/snippets/1576/) tag that allows spaces in any of the group names. It also fixes a small bug where if a group didn't exist none of the subsequent groups would be checked.
- tag
- templatetag
- user
- auth
- group
- permissions
- access-control
Generic views with row-level permission handling
These generic views extend default views so that they also do permission checking on per-object basis. * detail, update and delete - check access for user * create - create permissions for user on object * list - narrow object list with permissions Classes prefixed with Owned are example implementation where user has access to object if designed object attribute references him. Example: `create_article = OwnedCreateView.as_view(owner='creator', model=Article, form_class=ArticleForm, success_url='/articles/article/%(id)d')`
- generic-views
- permissions
Custom Command for Rebuilding Permissions and ContentTypes
Add this to any app as a custom management command.
- permission
- permissions
- management
- command
Class based generic views that automatically check permissions
Simple wrappers around the new class-based generic views (introduced in Django 1.3) that also check permissions. **Example Usage** *(views.py)*: from mymodule import RestrictedListView, RestrictedUpdateView class MyListView(RestrictedListView): model = MyModel class MyUpdateView(RestrictedUpdateView): model = MyModel and so on for Create and Delete.
- generic-views
- permissions
- class-based
middleware for user_passes_test
Middleware to decorate views with user_passes_test in a centralized, url-matching manner. Makes it easy to apply permissions across large sections or all of a site.
- auth
- permissions
- decorators
permission_required with multiple permissions
Suppose you want a decorator which takes multiple permissions. You can use permission_required which takes a single value.
- user
- auth
- permissions
Row-Level, URL-based permissions for FlatPages
I'm using Django's FlatPages, but I want to be able to restrict admin access to Users based on a FlatPage url. For example, User John Doe should be able to edit any FlatPage objects whose URL begins with `/johndoe/` (such as `/johndoe/about/` or `/johndoe/projects/whatever/`). For this to work, John Doe would already need the appropriate admin permissions for FlatPage (such as can_add and can_change). I have set this up as a separate *flatpage_addons* app. It consists of the **Permission** model, which maps a starting URL to one or more django Users. It consists of the minimal necessary admin code so Permissions can be created using the admin. The bulk of this code consists of the *ifhasflatpagepermission* template tag as well as the *flatpage_result_list* inclusion tag. The former works much like django's existing *if*, *else*, *endif* tags while the latter is modified from the django admin's *result_list* inclusion tag. This may not be the most elegant solution to my problem, but so far it works for me. Any comments or suggestions are welcome!
- urls
- url
- permission
- permissions
- flatpage
- flatpages
Link TemplateTag that checks for permissions and url address
This template tag was built to be used in web applications that are permission based. It renders the html for an html link tag if the user has permissions to access the view (if not, returns an empty string). It also checks if the current token is the active url address and, if so, adds class="active" to the html link for presentation purposes. Example usage: 1. {% url home as home_url %} {% get_link_if_allowed home_url "Home" %} 2. {% url project_dashboard project.id as project_dashboard_url %} {% get_link_if_allowed project_dashboard_url "Projects" %}
- template
- url
- permissions
- address
Permission Required Middleware
Wraps specified URL patterns with permission_required decorator. Allows you to quickly require a specific permission for an area of your site based only on a URL pattern. Assumes a passing knowledge of how Django permissions work and how to use them. See [User authentication in Django](http://docs.djangoproject.com/en/dev/topics/auth/#permissions) for more information.
- middleware
- permissions
22 snippets posted so far.