Automatically create and check dedicated permissions for all Django views
This Django app can create a dedicated permission for any or all views in a given app, manage their lifecycle (exclude some views, remove them all or remove the ones that no longer have an associated view) and also enforce the created permissions for the logged-in user. Users will only be able to process the views that they have been explicitly given the related permission to.
After adding view_perms to the INSTALLED_APPS list, use the create_view_perms Django management command to create all target permissions automatically. Permissions need to be created before being enforced. See the command help message for details about supported options.
To automatically enforce the created view permissions, add view_perms.middleware.check_view_perms.ViewPermissionMiddleware to the MIDDLEWARE list in Django settings. Make sure to put this middleware after django.contrib.auth.middleware.AuthenticationMiddleware.
It is possible to put some views in an ignore list, which results in them not having the permission created or enforced. This makes sense for parts of the application like authentication views (user needs some way to authenticate, after all), or for public-facing parts of the application. To do so add the fully qualified view name in VIEW_PERMS_IGNORE_LIST list in the Django settings module. This app enforces the views on a per-app basis and does not enforce view permissions for views that do not have a permission to their name (it’s permissive by default). So it’s possible to have apps that none of their views are permission enforced.
Names of permissions that this app created (ones which are displayed in Django admin interface) are composed of a fixed prefix (view_perm_) and the fully qualified view name (module name + . + view function or class name). If these names are too cryptic for users of the admin interface or you want them to be in a local language, it has been made possible for the programmer to provide a translation for this string by assigning the proper gettext translation to the __name_trans__ attribute of the view function or class.
Metadata
Release files for django-view-perms 0.1.3
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | Provenance | Actions |
|---|---|---|---|---|
| django-view-perms-0.1.3.tar.gz | 4.2 kB | Without provenance | Details for django-view-perms-0.1.3.tar.gz |
Release files / django-view-perms-0.1.3.tar.gz
| Download URL | django-view-perms-0.1.3.tar.gz |
|---|---|
| Size | 4.2 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
c3e7f8adcdeb658cf20d609089eff3e62019152cc5fb803dda541e0507a4173e
|
|
BLAKE2b-256 checksum How to use checksums |
0181b15dd0ed106c3a40f3d0d5103446ec05cff47017976b5fca598c19c11898
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
twine/1.10.0 pkginfo/1.2.1 requests/2.22.0 setuptools/41.4.0 requests-toolbelt/0.9.1 tqdm/4.19.5 CPython/3.6.9
|
Security for django-view-perms 0.1.3
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
No provenance found
None of the files in this release were uploaded with provenance metadata.
A note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.
To learn more about protecting yourself from malicious actors, visit our package security documentation.