-
Notifications
You must be signed in to change notification settings - Fork 113
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
Prevent panic on /remote.php/dav/files/ #1320
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. |
@refs can you provide info of the panic? |
https://cloud.drone.io/cs3org/reva/3145/13/6
This does "a good thing" - that now-passing scenario should be deleted from the expected-failures files. |
And look at https://cloud.drone.io/cs3org/reva/3145/6/7 tests/acceptance/features/apiOcisSpecific/apiShareWebdavOperations-propfind.feature:6
That bug-demo scenario is now producing a good result. It can be deleted. |
hi @labkode sorry for the radio silence, I was off sick the past week with some string children virus thing ... The panic I was referring to happens here: reva/internal/grpc/services/gateway/storageprovider.go Lines 2017 to 2020 in b2c4af4
and it is triggered when the URL looks just like in the description of this pull request:
I'm open to better alternatives and not just patch this :) |
@refs to trigger this condition one has to be on a "Shared folder" that must contain this structure. Anyways, the panic could have some nice logging to inform of the problem. |
// webdav endpoint is called without a path. i.e: /remote.php/dav/files | ||
if len(strings.Split(req.Ref.GetPath(), "/")) == 2 { | ||
return &provider.StatResponse{ | ||
Status: status.NewUnimplemented(ctx, nil, "method not allowed"), |
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.
A storage provider determines if the listing of the root folder is allowed based on permissions, not the gateway ...
@@ -95,6 +95,10 @@ func (s *svc) handlePropfind(w http.ResponseWriter, r *http.Request, ns string) | |||
case rpc.Code_CODE_PERMISSION_DENIED: | |||
log.Debug().Str("path", fn).Interface("status", res.Status).Msg("permission denied") | |||
w.WriteHeader(http.StatusMultiStatus) | |||
// TODO this is not a correct mapping. A new code SHOULD be added to the cs3apis. | |||
case rpc.Code_CODE_UNIMPLEMENTED: |
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 should check if the username is missing only in the ocs api. no need to push these quirks into storage providers or the cs3 api.
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.
agree, will contain the changes to ocdav only
@butonic changes are now contained to I thought of a middleware for not allowed methods to prevent from executing unnecessary logic but it might be an early optimization, but the fact that there is no way to catch this early on our router has some room for improvement 🚀 @labkode as per the behavior, it is captured here: https://github.com/owncloud/core/blob/18475dac812064b21dabcc50f25ef3ffe55691a5/tests/acceptance/features/apiWebdavOperations/propfind.feature honestly that LoC on Reva was running regardless of being on a shared folder or not, the stack trace shed some light on the path taken, I recommend having a look at it. I will dig into my configuration to discard it but we're not having a very complex use case, but we need to be sure. |
@@ -6,4 +6,4 @@ Feature: PROPFIND | |||
Scenario: PROPFIND to "/remote.php/dav/files" |
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.
If you check the line above you should find the after fixing all issues delete this Scenario and use the one from oC10 core
, meaning that AFAICT this complete feature file can be removed, as it is covered by the core tests.
- remove
tests/acceptance/features/apiOcisSpecific/apiShareWebdavOperations-propfind.feature
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.
Looks good from a test point of view - the related scenario in the core API tests now passes, and the local bug-demo scenario has been deleted.
@refs can we try to return false instead of raising a panic here? reva/internal/grpc/services/gateway/storageprovider.go Lines 2017 to 2020 in b2c4af4
The next step will be to find the storage provider and since it won't find any mapping for it, it will return the appropriate error. That's because this is raised a lot of other times when the user doesn't provide a correct path from any other clients. |
I'd say that's out of the scope of this one :D |
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.
Oh okay. No worries!
Currently requests to
/remote.php/dav/files/
result in panics since we cannot longer strip the user + destination from the url.We're reproducing this issue on the ocis storage. I wanted to tackle this at the storage level but sadly the panic happens before reaching the stat call.
I wonder if there is a better way to achieve the same results but instead letting the storage handle the way it interprets paths. Open to suggestions 💃