-
Notifications
You must be signed in to change notification settings - Fork 186
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
graph: user groupTypes property to indicate read-only groups #5974
Conversation
Thanks for opening this pull request! The maintainers of this repository would appreciate it if you would create a changelog item based on your changes. |
@JammingBen This should be of interest for you. Note: We opted for using the |
E2E tests failed: https://drone.owncloud.com/owncloud/ocis/21120/68/1 💥 To see the trace, please open the link in the console ...
npx playwright show-trace https://cache.owncloud.com/public/owncloud/ocis/21120/tracing/folder-alice-2023-4-4-10-50-52.zipnpx playwright show-trace https://cache.owncloud.com/public/owncloud/ocis/21120/tracing/folder-brian-2023-4-4-10-51-06.zip |
That's okay, I can work with that. Thanks for the heads-up! |
By setting GRAPH_LDAP_GROUP_CREATE_BASE_DN a distinct subtree can be configured where new LDAP groups are created. That subtree needs to be subordinate to GRAPH_LDAP_GROUP_BASE_DN. All groups outside for GRAPH_LDAP_GROUP_CREATE_BASE_DN are considered read-only and only groups below that DN can be updated and deleted. This is introduced for a pretty specific usecase where most groups are managed in an external source (e.g. a read-only replica of an LDAP tree). But we still want to allow the local administrator to create groups in a writeable subtree attached to that replica.
Kudos, SonarCloud Quality Gate passed! |
By setting GRAPH_LDAP_GROUP_CREATE_BASE_DN a distinct subtree can be configure
where new LDAP groups are created. That subtree needs to be subordinate to
GRAPH_LDAP_GROUP_BASE_DN. All groups outside for
GRAPH_LDAP_GROUP_CREATE_BASE_DN are considered read-only and only group below
that DN can be updated and deleted.
This is introduced for a pretty specific usecase where most groups are managed
in an external source (e.g. a read-only replica of an LDAP tree). But we still
want to allow the local administrator to create groups in a writeable subtree
attached to that replica.
To test this you can start ocis with
This will make all the demo groups "readonly" (indicated through "ReadOnly" value in "groupTypes":
Trying to update the group will end with an error (currently a 500), but I still need to fix that to return a 405 or 403.
Adding groups is still possible, but they'll endup in a seperate part of the LDAP tree:
Groups without the "ReadOnly" value in the groupTypes can be updated: