In Quick start was explained how to configure in two steps a security access for the view; but this require new code, to add a decorator or a mixin is new code.
It is also possible to use Django roles as middleware, for example under next two reasons:
For example, a requirement could be to all user needing to be logged-in to access any view of a particular application. Possible solutions to this could be (between others):
Note
To know more about application classification read after installation and configuration: Applications type.
In Django’s site settings file add django_roles.middleware.RolesMiddleware to MIDDLEWARE variable:
MIDDLEWARE = [
'django.contrib.sessions.middleware.SessionMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django_roles.middleware.RolesMiddleware',
...
]
Warning
Once middleware is installed, to change the behavior of a view belonging
to a particular application, at least a
django_roles.models.ViewAccess
object needs to be created. If
not, there will be no change while no application type is set
(Applications type).
The last step is to classify installed applications in security groups in Django site’s settings file.
With Django roles is possible to classify installed applications in three types. When application is classified in any of this three types, and the middleware installed, all access to applications’s views will have the default security of the type used to classify the application.
To know more about applications classification with Django roles read next: Applications type.
To setup applications type (and with this, their default security), is necessary to add any of the next three variables (Python lists) in settings file:
Note
By default if none of this 3 variables are declared in settings, all applications will be assumed as public, and their views will have public access security. Views will preserve their previous security status: for example, if a view was restricted by login_required it will remain restricted by the same logic.
List of applications not under site security.
The concept of NOT_SECURED application is to put together all applications not providing any view (no URLConf defined for the application). There are no views with the need to be secured.
Warning
If an application is classified as NOT_SECURED, and has views, anyone will be able to access this views.
Warning
If an application is classified as NOT_SECURED, and has views, no mather
if exists django_roles.models.ViewAccess
objects for those views,
NOT_SECURED condition will take precedence over
django_roles.models.ViewAccess
object.
List of applications mainly for public access.
PUBLIC applications have their views accessibly to anonymous user except an
object of type django_roles.models.ViewAccess
exist for a view and
its configuration is more restrictive than public.
Note
The behavior of views in PUBLIC applications that have other security challenge, will not be changed.
List of applications requiring at least the user to be Authorized
Application classified as a SECURED application will require the user to be logged.
Mar 15, 2019