Difference between revisions of "User Groups and Rights"
(Created page with "Rights can be assigned to users via User Groups. == Big Picture == Big Picture: User, Groups and Rights When a use...") |
|||
| Line 5: | Line 5: | ||
When a user requests an object from the web service (via the mobile app), the correct rights are evaluated. | When a user requests an object from the web service (via the mobile app), the correct rights are evaluated. | ||
The rights for an object are defined by programmatic customizing, overriding a respective method "CustomGroupRights". | The rights for an object are defined by programmatic customizing, overriding a respective method "CustomGroupRights". | ||
| − | A user can be (reverse) related to multiple user groups, which can also inherit from other user groups {{Version/ServerSince|4.9. | + | A user can be (reverse) related to multiple user groups, which can also inherit from other user groups {{Version/ServerSince|4.9.0}}. |
More specific group rights override rights assignments to more general groups. | More specific group rights override rights assignments to more general groups. | ||
The possibility to assign a user to different groups (not necessarily inheriting from each other) can lead to multiple (at first glance, conflicting) rights for different groups the user is in. | The possibility to assign a user to different groups (not necessarily inheriting from each other) can lead to multiple (at first glance, conflicting) rights for different groups the user is in. | ||
| Line 12: | Line 12: | ||
See [[HowTo:Configure_Users_and_User_Rights]]. | See [[HowTo:Configure_Users_and_User_Rights]]. | ||
== Rights Evaluation == | == Rights Evaluation == | ||
| − | As described in the Big Picture, there is a hierarchy to user groups, which is now also considered by the UBIK Content web service {{Version/ServerSince|4.9. | + | As described in the Big Picture, there is a hierarchy to user groups, which is now also considered by the UBIK Content web service {{Version/ServerSince|4.9.0}}. |
The evaluation process goes as follows: | The evaluation process goes as follows: | ||
# Get object's custom group rights | # Get object's custom group rights | ||
| Line 26: | Line 26: | ||
... where "RestrictiveNoRight" will be translated into "NoRight" and "RestrictiveRead" will be translated into "Read" ultimately - they are just used to have a way for active restriction instead of only extension (similar to the idea of blacklisting instead of whitelisting). | ... where "RestrictiveNoRight" will be translated into "NoRight" and "RestrictiveRead" will be translated into "Read" ultimately - they are just used to have a way for active restriction instead of only extension (similar to the idea of blacklisting instead of whitelisting). | ||
== Caching == | == Caching == | ||
| − | There was a complete overhaul of the user group caching mechanism of the UBIK Content web service {{Version/ServerSince|4.9. | + | There was a complete overhaul of the user group caching mechanism of the UBIK Content web service {{Version/ServerSince|4.9.0}}. |
It automatically establishes and maintains a working memory structure of the assignments between users and groups as well as the group hierarchy for fast access. | It automatically establishes and maintains a working memory structure of the assignments between users and groups as well as the group hierarchy for fast access. | ||
If change detection is enabled for the webservice (via AppSettings.config: setting UBIK.Service.EnableChangeNotifications = 1), the cache is updated as fast as possible as soon as any relevant change is detected. Otherwise, the cache is updated wrt. a login when this hasn't happened for some time and group data is being fetched. | If change detection is enabled for the webservice (via AppSettings.config: setting UBIK.Service.EnableChangeNotifications = 1), the cache is updated as fast as possible as soon as any relevant change is detected. Otherwise, the cache is updated wrt. a login when this hasn't happened for some time and group data is being fetched. | ||
| Line 35: | Line 35: | ||
* [[LOGIN|Logins]] | * [[LOGIN|Logins]] | ||
| + | [[Category:Coding|User Groups and Rights]] | ||
[[Category:Publishing|User Groups and Rights]] | [[Category:Publishing|User Groups and Rights]] | ||
[[Category:Studio|User Groups and Rights]] | [[Category:Studio|User Groups and Rights]] | ||
[[Category:Web service|User Groups and Rights]] | [[Category:Web service|User Groups and Rights]] | ||
| − | |||
Revision as of 15:26, 5 May 2025
Rights can be assigned to users via User Groups.
Big Picture
When a user requests an object from the web service (via the mobile app), the correct rights are evaluated. The rights for an object are defined by programmatic customizing, overriding a respective method "CustomGroupRights". A user can be (reverse) related to multiple user groups, which can also inherit from other user groups . More specific group rights override rights assignments to more general groups. The possibility to assign a user to different groups (not necessarily inheriting from each other) can lead to multiple (at first glance, conflicting) rights for different groups the user is in. However, the rights have a priority assigned to them, and the highest right is chosen in the end.
Rights Customization
See Configure Users and User Rights.
Rights Evaluation
As described in the Big Picture, there is a hierarchy to user groups, which is now also considered by the UBIK Content web service . The evaluation process goes as follows:
- Get object's custom group rights
- If they are not defined, default to "Write"
- Get user's group hierarchy
- Find the most specific group rights for this individual case
- Find the highest available right (first is highest):
- RestrictiveNoRight
- RestrictiveRead
- Write
- Read
- NoRight
... where "RestrictiveNoRight" will be translated into "NoRight" and "RestrictiveRead" will be translated into "Read" ultimately - they are just used to have a way for active restriction instead of only extension (similar to the idea of blacklisting instead of whitelisting).
Caching
There was a complete overhaul of the user group caching mechanism of the UBIK Content web service . It automatically establishes and maintains a working memory structure of the assignments between users and groups as well as the group hierarchy for fast access. If change detection is enabled for the webservice (via AppSettings.config: setting UBIK.Service.EnableChangeNotifications = 1), the cache is updated as fast as possible as soon as any relevant change is detected. Otherwise, the cache is updated wrt. a login when this hasn't happened for some time and group data is being fetched. One of the changes from the overhaul is that updates are not just scheduled asynchronously, but every cache access must await pending updates if they are relevant, while still aiming for a very fast evaluation - carefully weighing performance against integrity.
