Enabling apps to work in public shares. #2143
Conversation
|
Thanks for opening this pull request! The maintainers of this repository would appreciate it if you would create a changelog item based on your changes. |
C0rby
force-pushed
the
public-share-app-auth
branch
from
fd15ae1
to
4b7c8f6
Compare
C0rby
force-pushed
the
public-share-app-auth
branch
from
4b7c8f6
to
56bb05a
Compare
C0rby
force-pushed
the
public-share-app-auth
branch
from
fde951f
to
032a7b9
Compare
|
@C0rby I agree about the scopes part - the current implementation requires a lot of back and forth. I'll review the PR today, and we can take a look at how to improve the scopes enforcement. |
|
@C0rby I see that you're trying to verify IDs lying inside a shared folder. Such expansion of scopes happens here https://github.com/cs3org/reva/blob/master/internal/grpc/interceptors/auth/scope.go#L38 Apologies for the lack of documentation. I can create a separate PR to your PR to add that case. |
These changes are necessary to allow the user to use apps in public shares. Without these changes the requests would always fail because they couldn't be authenticated.
Up until now you couldn't see when a scope check failed because of a missing type assertion.
This solution is by far not pretty. But this is the smallest change I could find to support apps in public shares without completely rewriting the scopes code. If we want to use any app in a public share the app needs an authenticated context to access the files in the share. This is working fine since we can authenticate using the share token. But the resulting JWT contains a scope refering to the share resource. That means for a folder share it contains the resource ID of the shared folder. But if the app wants to access a specific file in the share it will request that file by ID. Because of that the old way of the public scope checker doesn't work because it would check if we are accessing the ID of the shared folder and not if we are accessing any file in that folder. Because of this problem I added two additional Stat requests so that I can check if the requested file is inside the shared folder.
C0rby
force-pushed
the
public-share-app-auth
branch
from
9af576c
to
24f0f78
Compare
|
We had to move certain requests to the extractRef method in the grpc interceptor but with that everything worked. 👍 |
I extended the scope checking to make it possible to use Apps (and the App Provider) in public shares.
I don't quite like this solution but we also haven't found a better alternative yet. Public share scopes work as long as the requests are path based but that is not always the case.
Maybe we need to rethink this scope implementation. It feels a bit to hacky and unflexible.
This solution is by far not pretty. But this is the smallest change I
could find to support apps in public shares without completely rewriting
the scopes code.
If we want to use any app in a public share the app needs an
authenticated context to access the files in the share. This is working
fine since we can authenticate using the share token. But the resulting
JWT contains a scope refering to the shared resource. That means for a
folder share it contains the resource ID of the shared folder. But if
the app wants to access a specific file in the share it will request
that file by ID. Because of that the old way of the public scope checker
doesn't work because it would compare or requested ID with the ID of
the shared folder and this would fail.
For this reason I added two additional Stat requests so that I
can check if the requested file is inside the shared folder.
This is the reva part of the required changes. The ocis part can be found in this PR: owncloud/ocis#2536