fix: signed URLs containing a hash

[JammingBen]

Encodes singed URLs so they can be resolved properly.

fixes opencloud-eu/opencloud#1808

[JammingBen]

@rhafer I thought I'd give this a shot, not sure if it's the best approach though. Also maybe there's a better utility method for encoding hashes? I think fully encoding the URL (including all slashes etc.) might be a bit too much.

[rhafer]

@rhafer I thought I'd give this a shot, not sure if it's the best approach though. Also maybe there's a better utility method for encoding hashes? I think fully encoding the URL (including all slashes etc.) might be a bit too much.

Thanks for looking into this. I think just replacing the # is not enough there are other characters that would need escaping when present in the path .

Provided that the path coming into the downloadURL function is not already partially escaped (I don't really know that from the top of my head) I think the proper fix would involve spliting the path into it's individual parts ( using strings.Split(path, "/') ) and then using url.JoinPath to get the correctly escaped path and use that construct the URL that you want to sign.

[JammingBen]

Provided that the path coming into the downloadURL function is not already partially escaped (I don't really know that from the top of my head) I think the proper fix would involve spliting the path into it's individual parts ( using strings.Split(path, "/') ) and then using url.JoinPath to get the correctly escaped path and use that construct the URL that you want to sign.

The path doesn't look escaped to me, I've tried it in authenticated and unauthenticated contexts.

[rhafer]

instead of the loop and the strings.Join I'd suggest to use:

encodedPath, err := url.JoinPath("", parts...)

That does the whole thing in one go.

[JammingBen]

Almost, it loses the leading /. I changed it to url.JoinPath("/", parts...). Which results in it always including a leading /, even if the given path doesn't have it initially. Which would probably not be an issue...? Or do you think it's better to check for that as well?

[rhafer]

When do you get a leading /? Does that ever happen?

[JammingBen]

In my observations, the given path always has a leading /. So it just stays this way. But if there would be a path without it, encodedPath would still end up with a leading / now. But again, that doesn't seem to happen, at least not that I can see.

[rhafer]

Ok. Then your change should be fine.