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

use share id to identify ocm shares #4630

Merged
merged 4 commits into from
Apr 26, 2024
Merged

Conversation

butonic
Copy link
Contributor

@butonic butonic commented Apr 15, 2024

We now use the share id to correctly identify ocm shares.

@butonic
Copy link
Contributor Author

butonic commented Apr 15, 2024

Now, while our webdav client will send the shared secret when making requests as the ocm share receiver:

func (d *driver) webdavClient(ctx context.Context, forUser *userpb.UserId, ref *provider.Reference) (*gowebdav.Client, *ocmpb.ReceivedShare, string, error) {
	id, rel := shareInfoFromReference(ref)

	share, endpoint, secret, err := d.getWebDAVFromShare(ctx, forUser, id)
	if err != nil {
		return nil, nil, "", err
	}

	endpoint, err = url.PathUnescape(endpoint)
	if err != nil {
		return nil, nil, "", err
	}

	// FIXME: it's still not clear from the OCM APIs how to use the shared secret
	// will use as a token in the bearer authentication as this is the reva implementation
	c := gowebdav.NewAuthClient(endpoint, gowebdav.NewPreemptiveAuth(BearerAuthenticator{token: secret}))
	if d.c.Insecure {
		c.SetTransport(&http.Transport{
			TLSClientConfig: &tls.Config{InsecureSkipVerify: true},
		})
	}

	return c, share, rel, nil
}

reva, when acting as the ocm share provider still needs to actually read the bearer auth ...

@butonic
Copy link
Contributor Author

butonic commented Apr 15, 2024

I think some of the confusion comes from comments like cs3org/OCM-API#57 (comment) which do not have a path property in the url that can identify the ocm share. In fact the sharedSecret / token is required to determine what content is to be served under /remote.php/webdav, which violates URLs as resource identitifiers in the first place. I thought we had moved away from that with /dav/files and /dav/public-files in oc10 ...

Well, with spaces at least we can finally provide actual URIs ... /dav/ocm/{ocm-share-id} is a proper URI ... we could even migrate that to /dav/spaces/{ocmproviderid}!{ocmspaceid}${ocm-shareid} ... maybe even use more than one ocmproviderid ... to directly route to the correct instance ... well ... maybe in the future. let us not go there now and stick to /dav/ocm.

Anyway, our /dav/ocm/ endpoint needs to learn bearer auth. The ocmshares auth manager currently uses the shareid to make a GetOCMShareByToken call, which is why this worked. It should actually use GetOCMShare with the ocm share id and then verify the bearer token with the shared secret.

Actually, GetOCMShare requires a user to be in the context, so we need to use the shared secret as the token to look up the share.

@butonic butonic marked this pull request as ready for review April 15, 2024 15:24
@butonic butonic requested review from labkode, a team and glpatcern as code owners April 15, 2024 15:24
@butonic
Copy link
Contributor Author

butonic commented Apr 15, 2024

@aduffeck I think this clarifies some of the confusion around authenticating OCM webdav requests. Do you remember how you set this up to test this ... The unit tests don't fully cover this. Needs to be added ...

@butonic
Copy link
Contributor Author

butonic commented Apr 15, 2024

@aduffeck shouldn't this condition be inverted:

func (s *service) GetOCMShare(ctx context.Context, req *ocm.GetOCMShareRequest) (*ocm.GetOCMShareResponse, error) {
	// if the request is by token, the user does not need to be in the ctx
	var user *userpb.User
	if req.Ref.GetToken() == "" {
		user = ctxpkg.ContextMustGetUser(ctx)
	}

@aduffeck
Copy link
Contributor

@aduffeck shouldn't this condition be inverted:

func (s *service) GetOCMShare(ctx context.Context, req *ocm.GetOCMShareRequest) (*ocm.GetOCMShareResponse, error) {
	// if the request is by token, the user does not need to be in the ctx
	var user *userpb.User
	if req.Ref.GetToken() == "" {
		user = ctxpkg.ContextMustGetUser(ctx)
	}

I don't think so. If no token is set (req.Ref.GetToken() == "") we require a user because we end up at https://github.com/cs3org/reva/blob/edge/pkg/ocm/share/repository/json/json.go#L309, otherwise we don't because we return at https://github.com/cs3org/reva/blob/edge/pkg/ocm/share/repository/json/json.go#L299 already.

Copy link
Contributor

@aduffeck aduffeck left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

@butonic butonic marked this pull request as draft April 19, 2024 21:31
@butonic
Copy link
Contributor Author

butonic commented Apr 19, 2024

To fix the ci I had to set up a debuggable environment ... and then I ran into owncloud/ocis#8564: sharingNG does not support OCM, yet.

Some ocis graph progress is in owncloud/ocis#8909, but it needs more work.

I'll commit the changes I made while dabbling with the setup to continue on it next week...

Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>
Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>
Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>
Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>
@butonic butonic marked this pull request as ready for review April 26, 2024 13:09
@butonic butonic merged commit 1fc6382 into cs3org:edge Apr 26, 2024
9 checks passed
@butonic butonic deleted the fix-ocm-share-id branch April 26, 2024 13:09
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.

None yet

2 participants