Skip to content
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

Merged
merged 7 commits into from
Aug 10, 2020
Merged

Ocfs lookup userid (update) #1052

merged 7 commits into from
Aug 10, 2020

Conversation

PVince81
Copy link
Contributor

@PVince81 PVince81 commented Aug 4, 2020

Resend of #1033

also to be able to continue working to fix the issues, if they still exist.

butonic added 3 commits July 30, 2020 14:46
Signed-off-by: Jörn Friedrich Dreyer <[email protected]>
Signed-off-by: Jörn Friedrich Dreyer <[email protected]>
@PVince81
Copy link
Contributor Author

PVince81 commented Aug 4, 2020

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

@PVince81
Copy link
Contributor Author

PVince81 commented Aug 4, 2020

litmus tests on new dav failing now:

4. propfind_d0........... WARNING: response href for wrong resource

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

@PVince81
Copy link
Contributor Author

PVince81 commented Aug 4, 2020

same failures as before. so there is more discrepancies in the setup

@PVince81
Copy link
Contributor Author

PVince81 commented Aug 6, 2020

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
@PVince81
Copy link
Contributor Author

PVince81 commented Aug 6, 2020

Pushed another missing setting

@PVince81
Copy link
Contributor Author

PVince81 commented Aug 6, 2020

  • investigate whether we could go to the gateway instead

@PVince81
Copy link
Contributor Author

PVince81 commented Aug 6, 2020

nice, the api tests pass.
next up: check that litmus failure

@PVince81
Copy link
Contributor Author

PVince81 commented Aug 6, 2020

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.
But the following makes everything pass:

docker run -e LITMUS_URL="http://172.17.0.1:20080/remote.php/dav/files/4c510ada-c86b-4815-8820-42cdf82c3d51" -e LITMUS_USERNAME="einstein" -e LITMUS_PASSWORD="relativity" -e TESTS="props" owncloud/litmus:latest

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...

Vincent Petry added 2 commits August 6, 2020 17:14
Fixed Drone config to use hard-coded UUID for einstein in the DAV URL.
@refs
Copy link
Member

refs commented Aug 7, 2020

Rebasing #1064 onto this fixes the createShare test scenarios through the provisioning API /cc @individual-it. To test it:

# on this branch
git rebase fix-error-propagation

Replace on OCIS
run:

make test-acceptance-api TEST_SERVER_URL=https://localhost:9200 TEST_OCIS=true OCIS_REVA_DATA_ROOT=/var/tmp/reva/ SKELETON_DIR=apps/testing/data/apiSkeleton BEHAT_FILTER_TAGS='~@skipOnOcis&&~@skipOnOcis-OC-Storage' TESTING_REMOTE_SYSTEM=true BEHAT_FEATURE=tests/acceptance/features/apiShareManagementBasic/createShare.feature

I will address the comments on #1064

@PVince81
Copy link
Contributor Author

This PR here is ready for review @labkode @butonic @refs

@@ -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"
Copy link
Contributor

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.

Copy link
Contributor Author

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"
Copy link
Contributor

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"
Copy link
Contributor

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}}"
Copy link
Contributor

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.

Copy link
Contributor Author

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"`
Copy link
Contributor

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},
Copy link
Contributor

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
Copy link
Contributor

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.

@butonic
Copy link
Contributor

butonic commented Aug 10, 2020

@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)

@PVince81
Copy link
Contributor Author

@butonic all changes that were made here contributed to make CI pass. Maybe we are missing tests for triggering #1052 (comment) ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants