I opened a ticket with the AZ CLI team as well regarding this issue. St=&se=&sp=rwdlacup&spr=https&sv=&ss=bqtf&srt=sco&sig=GkJC3PiP6NHa/QsNoIYMI/miHbLVdsIOCPinRJePKKg%3D Sv=&ss=bqtf&srt=sco&sp=rwdlacup&se=&st=&spr=https&sig=GkJC3PiP6NHa/QsNoIYMI/miHbLVdsIOCPinRJePKKg%3DĪz CLI Generated Token (Without re-arranging): Sv=&ss=bfqt&srt=sco&sp=rwdlacup&se=&st=&spr=https&sig=Xl4i%2Bsy%2Bg4ab7LstIguIlfXdOnhS6Slkdxe1CH0ptYE%3DĪz CLI Generated Token (With re-arranging): NOTE: These are not valid tokens I've changed the values in them so don't worry about redacting The only difference I can see is firstly the parameters of the SAS token are in a different order (Shouldn't matter though) e.g portal generated token starts with sv= where as Az CLI token starts with st= and secondly the sig= is always a few characters longer when using portal generated tokens. So, while the SAS token APIs (accessible via REST or AZ CLI) are quite happy to generate tokens with different date formats, I suspect that AzCopy isn't handling them verbatim and is breaking the signature as a result.Īz storage account generate-sas -account-name "$ACCOUNT" -account-key "$KEY" -expiry "$EXPIRE" -https-only -permissions acdlpruw -resource-types sco -services bfqtįor reference I've compared a valid SAS token generated via the Azure Portal and a token generated from AZ CLI with %3A changed to : and they are more or less identical in formatting so this is very confusing as to what is going on with azcopy. The sub-second precision is important: if you try to edit/remove the second component (even though they are all zeroes), then you invalidate the signature causing "AuthenticationFailed - Signature fields not well formed". The st and se values in the SAS token have the values: "T11:11:11.0000000Z".In the AzCopy failure output, timestamps are reported with lowercase T and Z, but it's not clear whether that's just a facet of the console output rather than an actual representation of the PUT operation. You CANNOT drop the case of the T or Z in the date format.In Postman, you can decode all the URL entries (%3A is a colon in the time, for example) without it affecting the signature.The SAS token DOES work when you manually make the PUT using a tool like Postman, so the SAS token is valid.GET User-Agent: Īnd here's an example of how I am trying to use it (real resources, but now nuked): Failed with error -> /Azure/azure-storage-blob-go/azblob.NewResponseError, /go/src//Azure/azure-storage-blob-go/azblob/zz_generated_response_error.go:28 Failed with error error starting the sync between source /tmp/content and destination Failed with error cannot list blobs for download. Log file is located at: /root/.azcopy/70e0f51f-593f-df42-6381-793d75977496.logĠ File Scanned at Source, 0 Files Scanned at DestinationĮrror performing the sync between source and destination. Make sure the value of Authorization header is formed correctly including the signature.Īccess-Control-Expose-Headers:
RESPONSE Status: 403 Server failed to authenticate the request. Make sure the value of Authorization header is formed correctly including the signature. = RESPONSE ERROR (ServiceCode=AuthenticationFailed) =ĭescription=Server failed to authenticate the request. Failed with error error starting the sync between source and destination /backup.įailed with error cannot list blobs for download.įailed with error -> /Azure/azure-storage-azcopy/vendor//Azure/azure-storage-blob-go/azblob.NewResponseError, /go/src//Azure/azure-storage-azcopy/vendor//Azure/azure-storage-blob-go/azblob/zz_generated_response_error.go:28
0 kommentar(er)
