Implementation of user management and multi-tenancy for OpenWISP (built with python & django).
Table of Contents:
- Deploy it in production
- Install stable version from pypi
- Install development version
- Setup (integrate in an existing django project)
- Installing for development
- Settings
- REST API
- Organization permissions
- Organization Owners
- Organization membership helpers
- Permissions helpers
- Authentication Backend
- Django REST Framework Permission Classes
- Django REST Framework Mixins
- Admin Multitenancy mixins
- Extend openwisp-users
- 1. Initialize your custom module
- 2. Install
openwisp-users - 3. Add
EXTENDED_APPS - 4. Add
openwisp_utils.staticfiles.DependencyFinder - 5. Add
openwisp_utils.loaders.DependencyLoader - 6. Inherit the AppConfig class
- 7. Create your custom models
- 8. Add swapper configurations
- 9. Create database migrations
- 10. Create the admin
- 11. Create root URL configuration
- 12. Import the automated tests
- Other base classes that can be inherited and extended
- Contributing
- Support
- Changelog
- License
An automated installer is available at ansible-openwisp2.
Install from pypi:
pip install openwisp-usersInstall tarball:
pip install https://github.com/openwisp/openwisp-users/tarball/masterAlternatively you can install via pip using git:
pip install -e git+git://github.com/openwisp/openwisp-users#egg=openwisp_usersINSTALLED_APPS in settings.py should look like the following:
INSTALLED_APPS = [
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.messages',
'django.contrib.staticfiles',
'openwisp_utils.admin_theme',
# overrides some templates in django-allauth
'openwisp_users.accounts',
'django_extensions',
'allauth',
'allauth.account',
'allauth.socialaccount',
# must come before the django admin
# to override the admin login page
'openwisp_users',
'django.contrib.admin',
'django.contrib.sites',
'rest_framework',
'rest_framework.authtoken',
'drf_yasg',
]also add AUTH_USER_MODEL, SITE_ID and AUTHENTICATION_BACKENDS
to your settings.py:
AUTH_USER_MODEL = 'openwisp_users.User'
SITE_ID = 1
AUTHENTICATION_BACKENDS = [
'openwisp_users.backends.UsersAuthenticationBackend',
]
urls.py:
from django.conf.urls import include, url
from django.contrib import admin
from django.contrib.staticfiles.urls import staticfiles_urlpatterns
urlpatterns = [
url(r'^admin/', include(admin.site.urls)),
url(r'^accounts/', include('allauth.urls')),
url(r'^api/v1/', include('openwisp_users.api.urls')),
]
urlpatterns += staticfiles_urlpatterns()For additional steps to properly configure allauth in your project,
please refer to their documentation:
allauth documentation installation section.
Install sqlite:
sudo apt-get install sqlite3 libsqlite3-dev openssl libssl-devInstall your forked repo:
git clone git://github.com/<your_fork>/openwisp-users
cd openwisp-users/
python setup.py developInstall test requirements:
pip install -r requirements-test.txtStart Redis
docker-compose up -dCreate database:
cd tests/
./manage.py migrate
./manage.py createsuperuserLaunch development server:
./manage.py runserverYou can access the admin interface at http://127.0.0.1:8000/admin/.
Run tests with:
# --parallel and --keepdb are optional but help to speed up the operation
./runtests.py --parallel --keepdb| type: | boolean |
| default: | False |
Indicates whether the admin section for managing OrganizationUser items
is enabled or not.
It is disabled by default because these items can be managed via inline items in the user administration section.
| type: | boolean |
| default: | True |
Indicates whether the admin section for managing OrganizationOwner items
is enabled or not.
Find out more information about organization owners.
| type: | boolean |
| default: | True |
Indicates whether the REST API is enabled or not.
| type: | str |
| default: | 100/day |
Indicates the rate throttling for the Obtain Authentication API endpoint.
Please note that the current rate throttler is very basic and will also count valid requests for rate limiting. For more information, check Django-rest-framework throttling guide.
To enable the API the setting
OPENWISP_USERS_AUTH_API
must be set to True.
A general live API documentation (following the OpenAPI specification) at /api/v1/docs/.
Additionally, opening any of the endpoints listed below directly in the browser will show the browsable API interface of Django-REST-Framework, which makes it even easier to find out the details of each endpoint.
/api/v1/user/token/
This endpoint only accepts the POST method and is used to retrieve the
Bearer token that is required to make API requests to other endpoints.
Example usage of the endpoint:
http POST localhost:8000/api/v1/user/token/ username=openwisp password=1234
HTTP/1.1 200 OK
Allow: POST, OPTIONS
Content-Length: 52
Content-Type: application/json
Date: Wed, 13 May 2020 10:59:34 GMT
Server: WSGIServer/0.2 CPython/3.6.9
Vary: Cookie
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
{
"token": "7a2e1d3d008253c123c61d56741003db5a194256"
}The authentication class openwisp_users.api.authentication.BearerAuthentication
is used across the different OpenWISP modules for authentication.
To use it, first of all get the user token as described above in
Obtain Authentication Token, then send
the token in the Authorization header:
# get token
TOKEN=$(http POST :8000/api/v1/user/token/ username=openwisp password=1234 | jq -r .token)
# send bearer token
http GET localhost:8000/api/v1/firmware/build/ "Authorization: Bearer $TOKEN"Here's a summary of the default permissions:
- All users who belong to the Administrators group and are organization
managers (
OrganizationUser.is_admin=True), have the permission to edit the organizations details which they administrate. - Only super users have the permission to add and delete organizations.
- Only super users and organization owners
have the permission to change the
OrganizationOwnerinline or delete the relation.
An organization owner is a user who is designated as the owner of a particular organization and this owner can not be deleted or edited by other administrators. Only the superuser has the permissions to do this.
By default, the first manager of an organization is designated as the owner of that organization.
If the OrganizationUser instance related to the owner of an organization is deleted
or flagged as is_admin=False, the admin interface will return an error informing
users that the operation is not allowed, the owner should be changed before attempting to do that.
The User model provides methods to check whether the user
is a member, manager or owner of an organization in an efficient way.
These methods are needed because an user may be administrator in one organization, but simple end-user is another organization, so we need to easily distinguish between the different use cases and at the same time avoid to generate too many database queries.
import swapper
User = swapper.load_model('openwisp_users', 'User')
Organization = swapper.load_model('openwisp_users', 'Organization')
user = User.objects.first()
org = Organization.objects.first()
user.is_member(org)
user.is_manager(org)
user.is_owner(org)
# also valid (avoids query to retrieve Organization instance)
device = Device.objects.first()
user.is_member(device.organization_id)
user.is_manager(device.organization_id)
user.is_owner(device.organization_id)Returns True if the user is member of the Organization instance passed.
Alternatively, UUID or str can be passed instead of an organization instance,
which will be interpreted as the organization primary key; this second option is
recommended when building the organization instance requires an extra query.
This check shall be used when access needs to be granted to end-users who need to consume a service offered by an organization they're member of (eg: authenticate to a public wifi service).
Returns True if the user is member of the Organization instance
and has the OrganizationUser.is_admin field set to True.
Alternatively, UUID or str can be passed instead of an organization instance,
which will be interpreted as the organization primary key; this second option is
recommended when building the organization instance requires an extra query.
This check shall be used when access needs to be granted to the managers of an organization users who need to perform administrative tasks (eg: download the firmware image of their organization).
Returns True if the user is member of the Organization instance
and is owner of the organization (checks the presence of an
OrganizationOwner instance for the user).
Alternatively, UUID or str can be passed instead of an organization instance,
which will be interpreted as the organization primary key; this second option is
recommended when building the organization instance requires an extra query.
There can be only one owner for each organization.
This check shall be used to avoid that managers would be able to take control of an organization and exclude the original owner without their consent.
The methods described above use the organizations_dict property method under
the hood, which builds a dictionary in which each key contains the primary key
of the organization the user is member of, and each key contains another dictionary
which allows to easily determine if the user is manager (is_admin) and owner
(is_owner).
This data structure is cached automatically and accessing it multiple times over the span of multiple requests will not generate multiple database queries.
The cache invalidation also happens automatically whenever an OrganizationUser
or an OrganizationOwner instance is added, changed or deleted.
Usage exmaple:
>>> user.organizations_dict
... {'20135c30-d486-4d68-993f-322b8acb51c4': {'is_admin': True, 'is_owner': False}}
>>> user.organizations_dict.keys()
... dict_keys(['20135c30-d486-4d68-993f-322b8acb51c4'])This attribute returns a list containing the primary keys of the organizations which the user can manage.
Usage example:
>>> user.organizations_managed
... ['20135c30-d486-4d68-993f-322b8acb51c4']This attribute returns a list containing the primary keys of the organizations which the user owns.
Usage example:
>>> user.organizations_owned
... ['20135c30-d486-4d68-993f-322b8acb51c4']The User model provides methods to check permissions in an efficient way
(without generating database queries each time the permissions are accessed).
The permissions property helper returns the user's permissions
from the cache, cache invalidation is handled automatically.
>>> user.permissions
... {'account.add_emailaddress',
'account.change_emailaddress',
'account.delete_emailaddress',
'account.view_emailaddress',
'openwisp_users.add_organizationuser',
'openwisp_users.add_user',
'openwisp_users.change_organizationuser',
'openwisp_users.change_user',
'openwisp_users.delete_organizationuser',
'openwisp_users.delete_user'}For superusers, the method returns True regardless of the permission passed to it.
While for other users, the method checks whether the user has the specified permission and
returns True or False accordingly.
It uses the permissions property helper under the hood to avoid generating database queries each time is called.
>>> user.has_permission('openwisp_users.add_user')
... TrueThe authentication backend in openwisp_users.backends.UsersAuthenticationBackend
allows users to authenticate using their
email or phone_number instead of their username.
Authenticating with the username is still allowed,
but email and phone_number have precedence.
It can be used as follows:
from openwisp_users.backends import UsersAuthenticationBackend
backend = UsersAuthenticationBackend()
backend.authenticate(request, phone_number, password)The custom Django REST Framework
permission classes IsOrganizationMember, IsOrganizationManager
and IsOrganizationOwner can be used in the API to ensure that the
request user is in the same organization as requested object and is
organization member, manager or owner respectively. Usage example:
from openwisp_users.api.permissions import IsOrganizationManager
from rest_framework import generics
class MyApiView(generics.APIView):
permission_classes = (IsOrganizationMember,)| type: | string |
| default: | organization |
organization_field can be used to define where to look to
find the organization of the current object.
In most cases this won't need to be changed, but it does need to
be changed when the organization is defined only on a parent object.
For example, in openwisp-firmware-upgrader,
organization is defined on Category and Build has a relation
to category, so the organization of Build instances is inferred from
the organization of the Category.
Therefore, to implement the permission class correctly, we would have to do:
from openwisp_users.api.permissions import IsOrganizationManager
from rest_framework import generics
class MyApiView(generics.APIView):
permission_classes = (IsOrganizationMember,)
organization_field = 'category__organization'This will translate into accessing obj.category.organization.
Ensure the queryset of your views make use of
select_related
in these cases to avoid generating too many queries.
The custom Django REST Framework
mixins FilterByOrganizationMembership, FilterByOrganizationManaged
and FilterByOrganizationOwned can be used in the API views to ensure
that the current user is able to see only the data related to their
organization when accessing the API view.
They work by filtering the queryset so that only items related to organizations the user is member, manager or owner of, respectively.
These mixins ship the Django REST Framework's
IsAuthenticated
permission class by default because the organization filtering
works only on authenticated users.
Always remember to include this class when
overriding permission_classes in a view.
Usage example:
from openwisp_users.api.mixins import FilterByOrganizationManaged
from rest_framework import generics
class UsersListView(FilterByOrganizationManaged, generics.ListAPIView):
"""
UsersListView will show only users from organizations managed
by current user in the list.
"""
pass
class ExampleListView(FilterByOrganizationManaged, generics.ListAPIView):
"""
Example showing how to extend ``permission_classes``.
"""
permission_classes = FilterByOrganizationManaged.permission_classes + [
# additional permission classes here
]Sometimes, the API view needs to check the existence and the
organization field of a parent object.
In such cases, FilterByParentMembership,
FilterByParentManaged and FilterByParentOwned can be used.
For example, given a hypotetical URL /api/v1/device/{device_id}/config/,
the view must check that {device_id} exists and that the user
has access to it, here's how to do it:
import swapper
from rest_framework import generics
from openwisp_users.api.mixins import FilterByParentManaged
Device = swapper.load_model('config', 'Device')
Config = swapper.load_model('config', 'Config')
# URL is:
# /api/v1/device/{device_id}/config/
class ConfigListView(FilterByParentManaged, generics.DetailAPIView):
model = Config
def get_parent_queryset(self):
qs = Device.objects.filter(pk=self.kwargs['device_id'])
return qsDjango REST Framework provides a browsable API which can be used to create HTTP requests right from the browser.
The relationship fields in this interface show all the relationships, without filtering by the organization the user has access to, which breaks multi-tenancy.
The FilterSerializerByOrgMembership, FilterSerializerByOrgManaged
and FilterSerializerByOrgOwned can be used to solve this issue.
Usage example:
from openwisp_users.api.mixins import FilterSerializerByOrgOwned
from rest_framework.serializers import ModelSerializer
from .models import Device
class DeviceSerializer(FilterSerializerByOrgOwned, ModelSerializer):
class Meta:
model = Device
fields = '__all__'- MultitenantAdminMixin: adding this mixin to a
ModelAdminclass will make it multitenant (users will only be able to see items of the organizations they manage or own). Setmultitenant_shared_relationsto the list of parameters you wish to have only organization specific options. - MultitenantOrgFilter: admin filter that shows only organizations the current user can manage in its available choices.
- MultitenantRelatedOrgFilter: similar
MultitenantOrgFilterbut shows only objects which have a relation with one of the organizations the current user can manage.
One of the core values of the OpenWISP project is Software Reusability, for this reason openwisp-users provides a set of base classes which can be imported, extended and reused to create derivative apps.
This will be extreme beneficial for you if you want to create additional fields for User model, example asking for Social Security Number of the User for registeration.
In order to implement your custom version of openwisp-users, you need to perform the steps described in this section.
When in doubt, the code in the test project and the sample app will serve you as source of truth: just replicate and adapt that code to get a basic derivative of openwisp-users working.
Premise: if you plan on using a customized version of this module, we suggest to start with it since the beginning, because migrating your data from the default module to your extended version may be time consuming.
The first thing you need to do is to create a new django app which will contain your custom version of openwisp-users.
A django app is nothing more than a
python package
(a directory of python scripts), in the following examples we'll call this django app
myusers, but you can name it how you want:
django-admin startapp myusers
Keep in mind that the command mentioned above must be called from a directory which is available in your PYTHON_PATH so that you can then import the result into your project.
Now you need to add myusers to INSTALLED_APPS in your settings.py,
ensuring also that openwisp_users has been removed:
INSTALLED_APPS = [
# ... other apps ...
# 'openwisp_users' <-- comment out or delete this line
'myusers'
]For more information about how to work with django projects and django apps, please refer to the django documentation.
Install (and add to the requirement of your project) openwisp-users:
pip install openwisp-users
Add the following to your settings.py:
EXTENDED_APPS = ('openwisp_users',)Add openwisp_utils.staticfiles.DependencyFinder to
STATICFILES_FINDERS in your settings.py:
STATICFILES_FINDERS = [
'django.contrib.staticfiles.finders.FileSystemFinder',
'django.contrib.staticfiles.finders.AppDirectoriesFinder',
'openwisp_utils.staticfiles.DependencyFinder',
]Add openwisp_utils.loaders.DependencyLoader to TEMPLATES
before django.template.loaders.app_directories.Loader in your settings.py:
TEMPLATES = [
{
'BACKEND': 'django.template.backends.django.DjangoTemplates',
'OPTIONS': {
'loaders': [
'django.template.loaders.filesystem.Loader',
'openwisp_utils.loaders.DependencyLoader',
'django.template.loaders.app_directories.Loader',
],
'context_processors': [
'django.template.context_processors.debug',
'django.template.context_processors.request',
'django.contrib.auth.context_processors.auth',
'django.contrib.messages.context_processors.messages',
],
},
}
]Please refer to the following files in the sample app of the test project:
You have to replicate and adapt that code in your project.
For more information regarding the concept of AppConfig please refer to
the "Applications" section in the django documentation.
For the purpose of showing an example, we added a simple social_security_number field in User model to the
models of the sample app in the test project.
You can add fields in a similar way in your models.py file.
For doubts regarding how to use, extend or develop models please refer to the "Models" section in the django documentation.
Once you have created the models, add the following to your settings.py:
# Setting models for swapper module
AUTH_USER_MODEL = 'myusers.User'
OPENWISP_USERS_GROUP_MODEL = 'myusers.Group'
OPENWISP_USERS_ORGANIZATION_MODEL = 'myusers.Organization'
OPENWISP_USERS_ORGANIZATIONUSER_MODEL = 'myusers.OrganizationUser'
OPENWISP_USERS_ORGANIZATIONOWNER_MODEL = 'myusers.OrganizationOwner'Substitute myusers with the name you chose in step 1.
Create database migrations:
./manage.py makemigrations
Now, manually create a file 0002_default_groups_and_permissions.py in the migrations directory just create by the makemigrations command and copy contents of the sample_users/migrations/0002_default_groups_and_permissions.py.
Apply database migrations:
./manage.py migrate
Refer to the admin.py file of the sample app.
To introduce changes to the admin, you can do it in two main ways which are described below.
For more information regarding how the django admin works, or how it can be customized, please refer to "The django admin site" section in the django documentation.
If the changes you need to add are relatively small, you can resort to monkey patching.
For example:
from openwisp_users.admin import (
UserAdmin,
GroupAdmin,
OrganizationAdmin,
OrganizationOwnerAdmin,
BaseOrganizationUserAdmin,
)
# OrganizationAdmin.field += ['example_field'] <-- Monkey patching changes exampleFor your convenience of adding fields in User forms, we provide the following functions:
When monkey patching the UserAdmin class to add add fields in the
"Add user" form, you can use this function. In the example, Social Security Number is added in the add form:
When monkey patching the UserAdmin class to add fields in the
"Change user" form to change / modify user form's profile section,
you can use this function. In the example, Social Security Number
is added in the change form:
When monkey patching the UserAdmin class you can use this
function to make field searchable and add it to the user
display list view. In the example, Social Security Number is added in the changelist view:
If you need to introduce significant changes and/or you don't want to resort to monkey patching, you can proceed as follows:
from django.contrib import admin
from openwisp_users.admin import (
UserAdmin as BaseUserAdmin,
GroupAdmin as BaseGroupAdmin,
OrganizationAdmin as BaseOrganizationAdmin,
OrganizationOwnerAdmin as BaseOrganizationOwnerAdmin,
OrganizationUserAdmin as BaseOrganizationUserAdmin,
)
from swapper import load_model
from django.contrib.auth import get_user_model
Group = load_model('openwisp_users', 'Group')
Organization = load_model('openwisp_users', 'Organization')
OrganizationOwner = load_model('openwisp_users', 'OrganizationOwner')
OrganizationUser = load_model('openwisp_users', 'OrganizationUser')
User = get_user_model()
admin.site.unregister(Group)
admin.site.unregister(Organization)
admin.site.unregister(OrganizationOwner)
admin.site.unregister(OrganizationUser)
admin.site.unregister(User)
@admin.register(Group)
class GroupAdmin(BaseGroupAdmin):
pass
@admin.register(Organization)
class OrganizationAdmin(BaseOrganizationAdmin):
pass
@admin.register(OrganizationOwner)
class OrganizationOwnerAdmin(BaseOrganizationOwnerAdmin):
pass
@admin.register(OrganizationUser)
class OrganizationUserAdmin(BaseOrganizationUserAdmin):
pass
@admin.register(User)
class UserAdmin(BaseUserAdmin):
passPlease refer to the urls.py file in the sample project.
For more information about URL configuration in django, please refer to the "URL dispatcher" section in the django documentation.
When developing a custom application based on this module, it's a good idea to import and run the base tests too, so that you can be sure the changes you're introducing are not breaking some of the existing features of openwisp-users.
In case you need to add breaking changes, you can overwrite the tests defined in the base classes to test your own behavior.
See the tests of the sample app to find out how to do this.
You can then run tests with:
# the --parallel flag is optional ./manage.py test --parallel myusers
Substitute myusers with the name you chose in step 1.
The following steps are not required and are intended for more advanced customization.
The API view classes can be extended into other django applications as well. Note that it is not required for extending openwisp-users to your app and this change is required only if you plan to make changes to the API views.
Create a view file as done in API views.py.
Remember to use these views in root URL configurations in point 11.
For more information about django views, please refer to the views section in the django documentation.
Please refer to the OpenWISP contributing guidelines.
See OpenWISP Support Channels.
See CHANGES.
See LICENSE.