-
Notifications
You must be signed in to change notification settings - Fork 112
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
Ocfs lookup userid (update) #1052
Conversation
Signed-off-by: Jörn Friedrich Dreyer <[email protected]>
Signed-off-by: Jörn Friedrich Dreyer <[email protected]>
Signed-off-by: Jörn Friedrich Dreyer <[email protected]>
the same tests fail on the reva repo, but they pass when I check out the whole of owncloud/ocis#409 and the connected deps. to align with ocis-reva defaults, I've pushed a commit that changes the default user layout for OCFS to use the opaque id @butonic FYI if tests pass then it will confirm that it's the ocis-reva change that makes it work. if changing the default in Reva is fine, we can keep it here |
litmus tests on new dav failing now:
it is likely that this will also fail in owncloud/ocis#409 then, but there is no litmus run there apparently, not sure if we should add it on that level @individual-it |
same failures as before. so there is more discrepancies in the setup |
Litmus test runs fine locally with this branch and owncloud/ocis#409. Strange... |
The user provider service now needs to be specified in the configurations
Pushed another missing setting |
|
nice, the api tests pass. |
Right, the Litmus failure is because the test run is using "einstein" as user instead of the uuid. If I run the test locally with "einstein" in the DAV URL I get the same failure.
now how to get this URL in Drone ? it seems that UUID is hard-coded here https://github.com/owncloud/ocis-accounts/blob/8de0530f31ed5ffb0bbb7f7f3471f87f429cb2ea/pkg/service/v0/service.go#L45 so would be safe to use for now... I'll adjust Drone... |
Fixed Drone config to use hard-coded UUID for einstein in the DAV URL.
Rebasing #1064 onto this fixes the createShare test scenarios through the provisioning API /cc @individual-it. To test it:
Replace on OCIS
I will address the comments on #1064 |
@@ -23,6 +23,7 @@ data_server_url = "http://localhost:11001/data" | |||
[grpc.services.storageprovider.drivers.owncloud] | |||
datadirectory = "/drone/src/tmp/reva/data" | |||
redis = "redis:6379" | |||
userprovidersvc = "localhost:18000" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Setting this will save a trip to the gateway. When left out it should fall back to the gatewaysvc
in the [shared]
section and work just as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the fallback did not seem to work, I had to add this
there was a strange thing where it was resolving some service, but that service did not implement the UserAPI, see #1033 (comment)
I didn't manage to find out what service it was resolving exactly
@@ -22,7 +22,8 @@ data_server_url = "http://localhost:11001/data" | |||
|
|||
[grpc.services.storageprovider.drivers.owncloud] | |||
datadirectory = "/var/tmp/reva/data" | |||
|
|||
redis = "redis:6379" | |||
userprovidersvc = "localhost:18000" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Setting this will save a trip to the gateway. When left out it should fall back to the gatewaysvc
in the [shared]
section and work just as well.
@@ -22,7 +22,8 @@ data_server_url = "http://localhost:11001/data" | |||
|
|||
[grpc.services.storageprovider.drivers.owncloud] | |||
datadirectory = "/var/tmp/reva/data" | |||
|
|||
redis = "redis:6379" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
setting redis
is optional. it defaults to localhost:6379
@@ -175,7 +179,7 @@ func (c *config) init(m map[string]interface{}) { | |||
c.Redis = ":6379" | |||
} | |||
if c.UserLayout == "" { | |||
c.UserLayout = "{{.Username}}" | |||
c.UserLayout = "{{.Id.OpaqueId}}" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This changes the default, but will prevent username changes from breaking the storage lookup.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I put this there to align to the change in ocis-reva which also changes the default. I hope it's ok.
Otherwise we'll have further discrepancies.
Redis string `mapstructure:"redis"` | ||
EnableHome bool `mapstructure:"enable_home"` | ||
Scan bool `mapstructure:"scan"` | ||
UserProviderEndpoint string `mapstructure:"userprovidersvc"` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need the UserProviderEndpoint
to look up a user by its username.
return nil, err | ||
} | ||
res, err := c.GetUser(ctx, &userpb.GetUserRequest{ | ||
UserId: &userpb.UserId{OpaqueId: usernameOrID}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When configuring the userprovider with ldap you need to configure a filter that checks both: the username attribute as well as the userid attribute.
@@ -881,6 +960,7 @@ func (fs *ocfs) ListGrants(ctx context.Context, ref *provider.Reference) (grants | |||
grants = make([]*provider.Grant, 0, len(aces)) | |||
for i := range aces { | |||
grantee := &provider.Grantee{ | |||
// TODO lookup uid from principal |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- The user lookup here needs to be implemented before the sharing tests can pass. at least I think they should fail somewhere without it.
@refs @PVince81 the TODO in the code for principal lookup is the only thing I think that needs to be implemented. I would expect the sharing tests to fail somewhere because of #1052 (comment) |
@butonic all changes that were made here contributed to make CI pass. Maybe we are missing tests for triggering #1052 (comment) ? |
Resend of #1033
also to be able to continue working to fix the issues, if they still exist.