* enhancement: add graph beta listPermissions endpoint
besides the new api endpoint it includes several utilities to simplify the graph api development.
* resolve drive and item id from the request path
* generic pointer and value utilities
* space root detection
* update GetDriveAndItemIDParam signature to return a error
* move errorcode package
* enhancement: add generic error code handling
* fix: rebase
When GRAPH_LDAP_SERVER_WRITE_ENABLED=false still allow updates of groups
if a distinct GRAPH_LDAP_GROUP_CREATE_BASE_DN is configured.
Partial-Fix: #6219
As the standard LDAP groups (groupOfNames) require at least one "member"
value to be present in a group, we have workarounds in place that add an
empty member ("") when creating a new group or when removing the last
member from the group. This can cause a race condition when e.g. multiple
request to remove members from a group an running in parallel, as we need
to read the group before we can construct the modification request. If
some other request modified the group (e.g. deleted the 2nd last member)
after we read it, we create non-working modification request.
These changes try to catch those errors and retry the modification
request once.
Fixes: #6170
In Active Directories UUID attributes such as "objectGUID" use a binary
syntax (oposed to the standard UUID syntax defined in RFC4530). This
introduces a flag to enable support for binary UUIDs as the id for users
and groups (similar to what the "users" and "groups" services already
support)
Fixes: #5815
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.
This adds some initial support for using $filter (as defined in the
odata spec) on the /users endpoint. Currently the following filters are
supported:
A single filter on `id` property of the `memberOf` relation of users.
To list all users that are members of a specific group:
```
curl 'https://localhost:9200/graph/v1.0/users?$filter=memberOf/any(m:m/id eq '262982c1-2362-4afa-bfdf-8cbfef64a06e')
```
A logical AND filteri on the `id` property of the `memberOf` relation of users.
`$filter=memberOf/any(m:m/id eq 262982c1-2362-4afa-bfdf-8cbfef64a06e) and memberOf/any(m:m/id eq 6040aa17-9c64-4fef-9bd0-77234d71bad0)`
This will cause at least two queries on the identity backend. The `and`
operation is performed locally.
Closes: #5487
