search

Azure / azure-storage-java

Microsoft Azure Storage Library for Java
https://docs.microsoft.com/en-us/java/api/overview/azure/storage
MIT License
189 stars 163 forks source link

SAS token become corrupted in BlobServiceClientBuilder.endpoint() #499

Closed nkryvych closed 4 years ago

nkryvych commented 4 years ago

Which service(blob, file, queue, table) does this issue concern?

Blob

Which version of the SDK was used?

12.0.0-preview.3

What problem was encountered?

When using BlobServiceClientBuilder().endpoint(endpoint) and passing SAS token as a part of the endpoint, then extracted token gets corrupted (probably by encode() method in the line: SASTokenCredential sasTokenCredential = SASTokenCredential.fromSASTokenString(URLParser.parse(url).sasQueryParameters().encode()); Example: original token: sv=2018-03-28&ss=bfqt&srt=sco&sp=rwdlacup&se=2019-09-24T17:00:45Z&st=2019-09-24T09:00:45Z

extracted token: sv=2018-03-28&spr=https&st=2019-09-24T09%3A00%3A45Z&se=2019-09-24T17%3A00%3A45Z

Have you found a mitigation/solution?

jaschrep-msft commented 4 years ago

Hi @nkryvych, thank you for reaching out to us. You seem to be using our new, re-architected library, and we're glad you're participating in our preview. Unfortunately, this repository houses our older SDK architecture. The code for what you're using lives here, alongside all the other libraries being rebuilt for a unified Azure development experience. We'd appreciate it if you could report that issue over there instead.

Looking at your example, however, I'm a bit confused as to what the issue you're encountering is, as well as its effects, since you present two differences in your example.

  1. The extracted token is missing the ss and srt query parameters. I'm not sure if this is because they were removed in our code, or if you were copy/pasting parameters that happened to be in a different order, as you're also clearly omitting the sig parameter for security reasons.
  2. The st and se parameter values have had each instance of : replaced with %3A. This is expected URL encoding. Although the service will accept either version of these parameters, encoding the : is considered more correct according to the RFC, and so we automatically apply this to our URLs.

When you submit this issue over there, your clarification, as well as steps to reproduce, would be helpful.

rickle-msft commented 4 years ago

@nkryvych We recently shipped a GA version of v12. If you are so inclined, please give this a try and let us know if you need more support. I am going to close this issue now as it has been inactive for a while, but please feel free to reopen it or post again if you feel it is necessary.