* Streamline the store implementation with and into reva
* Adapt to the cache/store refactoring in reva
* Streamline config options and their env vars
* Apply suggestions from code review
Co-authored-by: Martin <github@diemattels.at>
* Use the same database for all stores
* Bump reva
* Configure stat and filemetadata cache separately
* Fix default config
---------
Co-authored-by: Martin <github@diemattels.at>
* api test to get personal drive information of other users
* fix the broken personal drive listing
* removed scenario from expected failure after issue fixed
---------
Co-authored-by: Michael Barz <mbarz@owncloud.com>
As some setups don't have email addresses setup or reuse email
addresses, the keycloak search has to be done by username as that
is guaranteed to always be unique and defined.
This PR changes that.
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.
* api test for user trying to set their own personal space quota
* removed duplicate scenarios for set quota
* updated expected scenario
* fix wrong status code
* updated expected failure scenario after wrong status code fix
---------
Co-authored-by: Michael Barz <mbarz@owncloud.com>
* refactor middleware options
Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>
* use ocmemstore micro store implementaiton for token cache
Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>
* refactor ocis store options, support redis sentinel
Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>
* align cache configuration
Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>
* database and tabe are used to build prefixes for inmemory stores
Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>
* add global persistent store options to userlog config
Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>
* log cache errors but continue
Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>
* drup unnecessary type conversion
Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>
* Better description for the default userinfo ttl
Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>
* use global cache options for even more caches
Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>
* don't log userinfo cache misses
Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>
* default to stock memory store
Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>
* use correct mem store typo string
Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>
* split cache options, doc cleanup
Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>
* mint and write userinfo to cache async
Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>
* use hashed token as key
Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>
* go mod tidy
Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>
* update docs
Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>
* update cache store naming
Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>
* bring back depreceted ocis-pkg/store package for backwards compatability
Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>
* update changelog
Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>
* Apply suggestions from code review
Co-authored-by: kobergj <jkoberg@owncloud.com>
* revert ocis-pkg/cache to store rename
Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>
* add waiting for each step 50 milliseconds
* starlack check
---------
Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>
Co-authored-by: kobergj <jkoberg@owncloud.com>
Co-authored-by: Viktor Scharf <scharf.vi@gmail.com>
* upgrade to go1.19 and set go mem limit
* create ocis-pkg memlimit package
* use std automemlimit import
Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>
* import automemlimit in every ocis service, drop ocis-pkg/memlimit package
Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>
* bump go to 1.20
Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>
* drop unused config options and env vars
Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>
* update all version numbers, add doc
Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>
* fix lint
Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>
* update bingo and mockery
Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>
* bump golangci-lint
Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>
* fix selector test
Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>
* Update changelog/unreleased/enhancement-memlimit.md
Co-authored-by: kobergj <juliankoberg@googlemail.com>
---------
Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>
Co-authored-by: Willy Kloucek <wkloucek@owncloud.com>
Co-authored-by: kobergj <juliankoberg@googlemail.com>
Introduces a switch ('GRAPH_ASSIGN_DEFAULT_USER_ROLE') to allow to disable the assignment of the default role "User" to newly created users.
This will be used for setups where the role-assignments are populated either manually or during first login (e.g. from OIDC claims)
Fixes 5603
- Calling POST /graph/v1.0/users with userType not set will create a user as "Member"
- Calling POST /graph/v1.0/users with userType set as "Member" or "Guest" will create a user as "Member" or "Guest"
- Calling POST /graph/v1.0/users with userType set as anything but "Member" or "Guest" returns error
- Calling POST /graph/v1.0/education/users with userType not set will create a user as "Member"
- Calling POST /graph/v1.0/education/users with userType set as "Member" will create a user as "Member" and primary role as parameter specifies
- Calling POST /graph/v1.0/education/users with userType set as "Guest" will create a user as "Guest" and primary role as parameter specifies
- Calling POST /graph/v1.0/education/users with userType not set as anything but "Member" or "Guest" returns error
- Calling PATCH on /users or /education/users will update attribute in the same way as for POST
* A new config option for disabling users with the options "none", "attribute" and "group".
* When set to "none", there will be no enabledAttribute returned in user info and trying to change enabledAttribute will return an error
* Disable/enable group name DN as config parameter
* Adding/removing users to specified group on user update
* Changing log level for service initialization failure to error
* Adding helper methods to check if user is enabled/disabled + tests
Fixes#5554
This add support for combining filters on the /users with a logical "or" operation.
E.g. the filter:
"filter=(memberOf/any(m:m/id eq 509a9dcd-bb37-4f4f-a01a-19dca27d9cfa) or memberOf/any(m:m/id eq 262982c1-2362-4afa-bfdf-8cbfef64a06e)"
will return all users that are a member of either of the referenced group.
Closes: #5667
This should improve the processing of filters for appRoleAssignments
a bit when combining them with other filters. We try to avoid reading
the full user list if possible. And delay the processing of an
appRoleAssignments filter so we can apply it on a subset of user.
E.g. a filter:
`appRoleAssignments/any(m:m/appRoleId eq 71881883-1768-46bd-a24d-a356a2afdf7f) and memberOf/any(m:m/id eq 509a9dcd-bb37-4f4f-a01a-19dca27d9cfa)`
Will be reordered to first process the memberOf filter (which can be
executed without reading the full user list) and only apply the
appRoleAssignments filter on the resultset of the memberOf filter.
This add support for filtering on the `appRoleAssignment` relation of
users. E.g.
```
$filter=appRoleAssignments/any(m:m/appRoleId eq '262982c1-2362-4afa-bfdf-8cbfef64a06e')
```
combining it with a filter on groupMemberShip does also work:
```
$filter=memberOf/any(m:m/id eq '262982c1-2362-4afa-bfdf-8cbfef64a06e') and appRoleAssignments/any(m:m/appRoleId eq 'd7beeea8-8ff4-406b-8fb6-ab2dd81e6b11')
```
The filter is still very inefficient as it always needs to get the full
users list. We need to adapt it to only filter on a subset of users when
using this filter 'and' combined with other filters.
Closes: #5488
* Add http endpoint to list permissions
Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>
* extract handler registration
Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>
* use generated protobuf
Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>
* update permissions mock in graph service
Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>
* add unit test
Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>
* return correct userid
Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>
* assert error message type in tests
Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>
---------
Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>
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
