-
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
Public Links Download / Upload #822
Conversation
return &PathTranslator{ | ||
dir: filepath.Dir(p), | ||
base: filepath.Base(p), | ||
token: strings.Split(p, "/")[2], |
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 does not change for requests to the public storage
@refs two questions: What is the purpose of the path translator? What do you need to check for owncloud storage? |
Hi @labkode :)
It's a dumb abstraction, as I'm not so familiar with the storages just yet, all the path operations got me a little lost, so instead of having 4 different variables this layer helps me with the steps. Needless to say, it can be removed in favor of concise code.
The way I test this is with the Owncloud storage, where a path looks like |
Something is fishy:
This happens both with and without the fix from #848 merged into this branch checked out locally. On master and on #848 all alone the service starts fine. |
} | ||
|
||
if isOCStorage(tokenPath) { | ||
base := strings.Join(strings.Split(tokenPath, "/")[3:], "/") |
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.
are paths normalized ? could there be leaks in case of double slashes ?
does Golang have a library for properly handling paths and deduplicating separators ?
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 path
package
ok seems there are some new config values: https://github.com/cs3org/reva/pull/822/files#diff-93a24189b46141fd854292e592c3be2aR56 @refs please provide more info about how to test this |
probably also need to extend the default config structure to have default settings for these new config values ? |
ok, so it seems this PR also needs owncloud/ocis-reva#258 @refs would be good to always explicitly list the requirements for testing in the top post |
|
I managed to run some API tests locally: It seems the upload has troubles renaming the file to the final location:
To reproduce, run this command in the owncloud/core repo with the test setup from https://owncloud.github.io/extensions/ocis_reva/testing/#use-existing-tests-for-bdd
|
oh, it seems it's the regular upload, not public link that has troubles:
|
unrelated to this PR, also happens on reva master... hmmm |
I've raised https://github.com/owncloud/ocis-reva/issues/280 for when uploading to a non-existing folder. I suspect that the skeleton files for the test have changed so I'll need to adjust the test |
ok, so I ran the tests with the wrong skeleton folder... with that in place, the test runs further. let's try other tests... |
the test tests/acceptance/features/apiSharePublicLink1/createPublicLinkShare.feature:170 had troubles creating the share because of a permission issue, PR here to fix it: #852 now with that fix applied, the downloaded content is empty:
|
@refs please have a look at the second stat call in "put.go". The bug is that it reuses Here a possible patch:
|
|
||
// refFromToken returns the path for the publicly shared resource. | ||
func (s *service) refFromToken(ctx context.Context, token string) (*provider.Reference, error) { | ||
driver, err := pool.GetPublicShareProviderClient(s.conf.DriverAddr) |
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.
duplicated from pathFromToken except for the return statement that wraps it
remove and use pathFromToken instead
|
alternate approach in #872 |
in #872 we have the public download working by talking to the gateway instead of storage after translating the paths, this obsoletes the need for a public link data provider and removes the need to know about the underlying storage as the gateway takes care of that by resolving the matching storage provider. |
obsoleted byd #877, can be closed |
Downloads from a public link. There are a few loose ends:
DataGateway
Basic functionality for downloading using a configured data provider however is there.