Calling Azure::Storage::Common::Core::Auth::SharedAccessSignature#generate_service_sas_token with a path ending in with one or multiple . generates the signature using the . as expected, however Azure reports that the string used doesn't contain the trailing slashes.
However accessing the URL returns a AuthenticationFailed error with a signature mismatch, because apparently the backend uses the filename without any trailing periods to verify:
Signature did not match. String to sign used was
r\n\n2021-05-27T10:58:10Z\n/blob/catalinrepro/uploads/@hashed/d4/73/d4735e3a265e16eee03f59718b9b5d03019c07d8b6c51f90da3a666eec13ab35/4842ef328558dd3e3b430308259541b1/test\n\n\nhttps\n2018-11-09\nb\n\n\n\n\n\n
Compared to the one we use to sign:
Azure::Storage::Common::Core::Auth::SharedAccessSignature.define_method(:generate_service_sas_token) do |*args|
binding.irb
self.old_method(*args)
end
irb(main):042:0> local_file.url(expire_at)
irb(#<Azure::Storage::Common::Core::Auth::SharedAccessSignature:0x00007f1013e39890>):001:0> signable_string_for_service('blob', args[0], args[1])
=> "r\n\n2021-05-27T11:29:28Z\n/blob/catalinrepro/uploads/@hashed/d4/73/d4735e3a265e16eee03f59718b9b5d03019c07d8b6c51f90da3a666eec13ab35/4842ef328558dd3e3b430308259541b1/test.\n\n\nhttps\n2018-11-09\nb\n\n\n\n\n\n"
The Azure storage docs for blob names do mention avoiding this scenario:
Avoid blob names that end with a dot (.), a forward slash (/), or a sequence or combination of the two. No path segments should end with a dot (.).
Should Azure::Storage::Common::Core::Auth::SharedAccessSignature#generate_service_sas_token maybe have logic to strip trailing periods on the path if service_type is b?
Calling
Azure::Storage::Common::Core::Auth::SharedAccessSignature#generate_service_sas_token
with a path ending in with one or multiple.
generates the signature using the.
as expected, however Azure reports that the string used doesn't contain the trailing slashes.We've ran into this in https://gitlab.com/gitlab-org/gitlab/-/issues/332027 - the specific example from there is:
However accessing the URL returns a
AuthenticationFailed
error with a signature mismatch, because apparently the backend uses the filename without any trailing periods to verify:Compared to the one we use to sign:
The Azure storage docs for blob names do mention avoiding this scenario:
Should
Azure::Storage::Common::Core::Auth::SharedAccessSignature#generate_service_sas_token
maybe have logic to strip trailing periods on thepath
ifservice_type
isb
?