We were using stretchr/testify and test-go/testify inconsitently and
sometimes mixed in the same tests. This can cause very strange issue,
e.g when using things like mock.MatchedBy().
This moves all our code to stretchr/testify, which seems to be far
more active and maintained then test-go/testify.
* enhancement: use reva client pool selectors
register mock service to registry and pass tests
* enhancement: bump reva
* Fix a couple of linter issues
---------
Co-authored-by: Ralf Haferkamp <rhaferkamp@owncloud.com>
The previous implementation was using an unlimited TTL which would cause
problems in scale out deployments where multiple instances of the settings
service are running.
Fixes: #5067
Share the same instance between the HTTP and the GRPC service. This is
in preparation for moving the cache of the metadata storage backend to a
go-micro/store based implementation. By sharing the same service instance in
the HTTP and GRPC services we can avoid the usage of global variables for the
caches, which will make the move to the go-micro/store implementation simpler.
For certain setups we don't need the ADMIN_USER_ID to be set. It is
mainly needed for bootstrapping the internal idm and the initial role
assignment. If roles are assigned by other means (e.g. OIDC claims
in the future) we don't need it.
This makes the ADMIN_USER_ID optional, also if ADMIN_USER_ID is unset
we don't need to configure a password for the admin user. We will still
generated the admin_id and password when running 'ocis init', but it is
ok to run manual setups without those settings.
When using metadata backend the default role assignments for the demo users
where create independed of whether the demo users are were actually requested
to be created. This also fixes the name of the env var for enabling the demo
users. This was missed when moving from the accounts service to graph/idm for
user management.
When using the metadata storage (the current default) the default role
assignments were recreated at every start of the settings service. Leading to
duplicated role assignments
Fixes: #3432
* 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>
ownCloud Web recently transitioned to Vue3. The settings ui is still
written in Vue2. Since it's pretty much unused we won't take the efforts
of upgrading it to Vue3.
* walk and log chi routes, ocs cleanup
Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>
* make linter happy
Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>
Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>
* bump libregraph-go lib
Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>
* add appRoleAssignment stubs
Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>
* add get application stub
Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>
* fetch appRoles for application from settings service
Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>
* initial list appRoleAssignments implementation
Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>
* initial create appRoleAssignment implementation, extract assignmentToAppRoleAssignment, configurable app id and displayname
Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>
* initial delete appRoleAssignment implementation, changed error handling and logging
Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>
* initial expand appRoleAssignment on users
Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>
* test user expand appRoleAssignment
Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>
* test appRoleAssignment
Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>
* fix education test by actually using the mocked roleManager
Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>
* test getapplication
Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>
* list assignments
Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>
* use common not exists error handling
Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>
* default to just 'ownCloud Infinite Scale' as application name
Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>
* fix store_test
Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>
* roll application uuid on init
Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>
* fix tests
Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>
* extract method
Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>
* Apply suggestions from code review
Co-authored-by: Michael Barz <mbarz@owncloud.com>
Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>
Co-authored-by: Michael Barz <mbarz@owncloud.com>
When using an external user management we need to allow users to self-assign
the default role. This adds an explicit check for that to the settings service.
This also means we no longer need to fiddle with the account id in the proxy
upon first login.
Fixes: #5045
