mirror of
https://gitlab.com/allianceauth/allianceauth.git
synced 2025-07-10 13:00:16 +02:00
a33c8c14ee
* Add service access permissions and migration `ENABLE_AUTH_<servicename> = True` will have the new permission applied to the settings configured `DEFAULT_AUTH_GROUP` group or `Member` if none is configured. `ENABLE_BLUE_<servicename> = True` will have the new permission applied to the settings configured `DEFAULT_BLUE_GROUP` group or `Blue` if none is configured. * Move views and hooks to permissions based access * Remove access restriction to services view Hypothetically non-member/blues could be granted permission to access services manually as desired now. A user that has no permissions to access any services will see a blank services list. * Remove obsolete service settings * Remove references to obsolete settings * Adjusted tests to support permissions based access * Fix incorrectly named permissions * Add simple get_services generator function * Added signals for user and groups perm changes * Update validate_services to support permissions deactivate_services removed as its surplus to requirements. * Removed state parameter from validate_services calls * Update tests to support signals changes * Fix incorrect call to validate_services task * Fix validate_services and test * Add validate_user to changed user groups signal * Added tests for new signals * Remove unnecessary post_add signals * Added documentation for service permissions * Added detection for members with service active If there are any service users in the Member or Blue groups active, then the permission will be added to the respective Member or Blue group. This means its no longer necessary to maintain the service enablesettings to migrate to permissions based service. Remove obsolete state based status checking
38 lines
2.5 KiB
Markdown
38 lines
2.5 KiB
Markdown
# Service Permissions
|
|
```eval_rst
|
|
.. note::
|
|
New in 1.15
|
|
```
|
|
|
|
In the past, access to services was dictated by a list of settings in `settings.py`, granting access to each particular service for Members and/or Blues. This meant that granting access to a service was very broad and rigidly structured around these two states.
|
|
|
|
## Permissions based access
|
|
|
|
Instead of granting access to services by the previous rigid structure, access to services is now granted by the built in Django permissions system. This means that service access can be more granular, allowing only certain groups, for instance Corp CEOs, or even individual user access to each enabled service.
|
|
|
|
```eval_rst
|
|
.. important::
|
|
If you grant access to an individual user, they will have access to that service regardless of whether or not they are a member.
|
|
```
|
|
|
|
Each service has an access permission defined, named like `Can access the <service name> service`.
|
|
|
|
To mimick the old behaviour of enabling services for all members, you would select the `Member` group from the admin panel, add the required service permission to the group and save. Likewise for Blues, select the `Blue` group and add the required permission.
|
|
|
|
A user can be granted the same permission from multiple sources. e.g. they may have it granted by several groups and directly granted on their account as well. Auth will not remove their account until all instances of the permission for that service have been revoked.
|
|
|
|
## Removing access
|
|
|
|
```eval_rst
|
|
.. danger::
|
|
Access removal is processed immediately after removing a permission from a user or group. If you remove access from a large group, such as Member, it will immediately remove all users from that service.
|
|
```
|
|
|
|
When you remove a service permission from a user, a signal is triggered which will activate an immediate permission check. For users this will trigger an access check for all services. For groups, due to the potential extra load, only the services whose permissions have changed will be verified, and only the users in that group.
|
|
|
|
If a user no longer has permission to access the service when this permissions check is triggered, that service will be immediately disabled for them.
|
|
|
|
### Disabling user accounts
|
|
|
|
When you unset a user as active in the admin panel, all of that users service accounts will be immediately disabled or removed. This is due to the built in behaviour of Djangos permissions system, which will return False for all permissions if a users account is disabled, regardless of their actual permissions state.
|