@robertmglynn , thanks for your detailed post. Just to ensure, is it happening only with files where you change the extension type? Like for instance, .exe to .jpeg and such?
Azure REST API Accepted for some file types, Forbidden for other file types
I'm using the Azure REST API to copy files from one folder to another (https://learn.microsoft.com/en-us/rest/api/storageservices/copy-file). All files and folders are in the same account, in the same file share, uploaded by the same user account via the portal. I'm using SharedKey auth and the key is the same for all requests. The authentication portion code is from https://github.com/Azure-Samples/storage-dotnet-rest-api-with-auth.git and the requests are made from that code, adapted for Get/Copy requests.
My problem is that attempting to copy some files results in a 403 Forbidden response. This appears to be linked to the file type. The file extension is not a factor. I can copy .jpg (and .jpeg), .txt, and .pdf files. I cannot copy .exe, .mp4 or .zip files. If I rename a .exe file with a .jpg extension on my dev machine, then upload to /source folder via the portal, attempting to copy via the API results in a Forbidden response. File size is not a factor, I have actual .jpg files copy successfully that are larger than the problem file types.
I cannot find any example or explanation for this. Testing details below.
(replace [myaccount] with a string, [some guid] confirmed not null and valid guid value)
Directories under my file share are:
/destination
/source
Test 01: copy th.jpeg from source to destination
Request:
{Method: PUT, RequestUri: 'https://[myaccount].file.core.windows.net/[myshare]/destination/th.jpeg', Version: 1.1, Content: <null>, Headers:
{
x-ms-date: Wed, 27 Jan 2021 15:13:28 GMT
x-ms-version: 2017-04-17
x-ms-copy-source: https://[myaccount].file.core.windows.net/[myshare]/source/th.jpeg
Authorization: SharedKey [myaccount]:18sCuTcbEOA5TLC11hCEH0pkK93Ln/Wk1BSRy0ytEAA=
Request-Id: [value is same as failed requests]
}}
Response:
{StatusCode: 202, ReasonPhrase: 'Accepted', Version: 1.1, Content: System.Net.Http.HttpConnectionResponseContent, Headers:
{
ETag: "0x8D8C2D61A12C96B"
Server: Windows-Azure-File/1.0
Server: Microsoft-HTTPAPI/2.0
x-ms-request-id: [some guid]
x-ms-version: 2017-04-17
x-ms-copy-id: [some guid]
x-ms-copy-status: success
Date: Wed, 27 Jan 2021 15:13:28 GMT
Content-Length: 0
Last-Modified: Wed, 27 Jan 2021 15:13:28 GMT
}}
same requests for the following files work:
11866.jpg 207.77 KiB
pancakes.jpg 6.26 MiB
subcontractor.pdf 232.36 KiB
text.txt 908 B
Test 02: copy 2M.jpg from source to destination
Request:
{Method: PUT, RequestUri: 'https://[myaccount].file.core.windows.net/[myshare]/destination/2M.jpg', Version: 1.1, Content: <null>, Headers:
{
x-ms-date: Wed, 27 Jan 2021 15:16:51 GMT
x-ms-version: 2017-04-17
x-ms-copy-source: https://[myaccount].file.core.windows.net/[myshare]/source/2M.jpg
Authorization: SharedKey [myaccount]:QWYuXaE0Djs8k3xtOYMpZ831zX/mVD1Kwx1jgwDK9Oo=
Request-Id: [value is same as successful requests]
}}
Response:
{StatusCode: 403, ReasonPhrase: 'Server failed to authenticate the request. Make sure the value of Authorization header is formed correctly including the signature.', Version: 1.1, Content: System.Net.Http.HttpConnectionResponseContent, Headers:
{
Server: Microsoft-HTTPAPI/2.0
x-ms-request-id: [some guid]
Date: Wed, 27 Jan 2021 15:16:51 GMT
Content-Length: 763
Content-Type: application/xml
}}
same requests for the following files fail with the same status and reason:
15M.jpg 15.13 MiB
2M.jpg 2.77 MiB
7M.jpg 7.77 MiB
FCVideo.jpg 106.09 MiB
FCVideo.mp4 106.09 MiB
FluentConference.zip 1020.49 MiB
All jpg files in the above list are actually either .exe or .zip files that have been renamed.
2 answers
Sort by: Most helpful
-
-
Vignesh Balasubramanian 1 Reputation point
2021-02-03T17:31:23.067+00:00 @robertmglynn , sorry for the delay, didn't get notified. I understand. Thank you for the explanation. Are you using Shared Key as part of authorization header in Postman? I am not quite sure modifying the file type would work, if you look at the error message from Postman response and compare with the shared key that you are generating, there might be some difference which is why the Put calls are failing.