onedrive-api-docs: Problems uploading into uploadUrl: 401 Unauthorized
This started happening sometime between April 18-22. We can obtain the upload URL for a new file (so we create the upload session), but when uploading the first chunk, it fails with a 401 Unauthorized error. This only happens when using an ADMINISTRATOR access token. When using a single-user access token, this does not happen. So this applies to OneDrive for Business (with administrator token) and not single user.
Request (to get the upload URL):
> POST /personal/{email}/_api/v2.0/drive/root:/robots2.txt:/createUploadSession HTTP/1.1
Accept: application/json
Authorization: Bearer {access_token}
User-Agent: GuzzleHttp/6.1.1 curl/7.35.0 PHP/5.6.29-1+deb.sury.org~trusty+1
Content-Type: application/json
Host: {tenant}-my.sharepoint.com
Content-Length: 56
Response:
< HTTP/1.1 200 OK
< Cache-Control: private, max-age=0
< Transfer-Encoding: chunked
< Content-Type: application/json;odata.metadata=minimal;odata.streaming=true;IEEE754Compatible=false;charset=utf-8
< Expires: Mon, 10 Apr 2017 21:30:46 GMT
< Last-Modified: Tue, 25 Apr 2017 21:30:46 GMT
* Server Microsoft-IIS/8.5 is not blacklisted
< Server: Microsoft-IIS/8.5
< P3P: CP="ALL IND DSP COR ADM CONo CUR CUSo IVAo IVDo PSA PSD TAI TELo OUR SAMo CNT COM INT NAV ONL PHY PRE PUR UNI"
< X-SharePointHealthScore: 0
< X-SP-SERVERSTATE: ReadOnly=0
< ODATA-VERSION: 4.0
< SPClientServiceRequestDuration: 1100
< SPRequestDuration: 1235
< X-AspNet-Version: 4.0.30319
< SPRequestGuid: 2f93eb9d-e033-4000-e1b2-d0dc23d8504c
< request-id: 2f93eb9d-e033-4000-e1b2-d0dc23d8504c
< Strict-Transport-Security: max-age=31536000
< X-FRAME-OPTIONS: SAMEORIGIN
< X-Powered-By: ASP.NET
< MicrosoftSharePointTeamServices: 16.0.0.6413
< X-Content-Type-Options: nosniff
< X-MS-InvokeApp: 1; RequireReadOnly
< X-MSEdge-Ref: Ref A: 0CB89A006F6D4DDDB7067CD67FBDAD30 Ref B: CH1EDGE0521 Ref C: Tue Apr 25 14:30:47 2017 PST
< Date: Tue, 25 Apr 2017 21:30:47 GMT
<
We got the uploadUrl, we now try to upload:
> PUT /personal/{email}/_api/v2.0/drive/items/01VKXHYLN6Y2GOVW7725BZO354PWSELRRZ/uploadSession?guid='guid'&path='~tmpE3_robots2.txt'&overwrite=True&rename=False&access_token={access_token}
HTTP/1.1
Accept: application/json
Authorization: Bearer {access_token}
User-Agent: GuzzleHttp/6.1.1 curl/7.35.0 PHP/5.6.29-1+deb.sury.org~trusty+1
Host: {tenant}-my.sharepoint.com
Content-Range: bytes 0-22379/22380
Content-Length: 22380
Response:
< HTTP/1.1 401 Unauthorized
< Content-Length: 0
* Server Microsoft-IIS/8.5 is not blacklisted
< Server: Microsoft-IIS/8.5
< P3P: CP="ALL IND DSP COR ADM CONo CUR CUSo IVAo IVDo PSA PSD TAI TELo OUR SAMo CNT COM INT NAV ONL PHY PRE PUR UNI"
< WWW-Authenticate: Bearer realm="96f92206-b32e-4ed0-8020-9e0984ce71c4",client_id="00000003-0000-0ff1-ce00-000000000000",trusted_issuers="00000001-0000-0000-c000-000000000000@*,https://sts.windows.net/*/,00000003-0000-0ff1-ce00-000000000000@90140122-8516-11e1-8eff-49304924019b",authorization_uri="https://login.windows.net/common/oauth2/authorize"
< SPRequestGuid: 2f93eb9d-007d-4000-e6b6-6c8efd18b843
< request-id: 2f93eb9d-007d-4000-e6b6-6c8efd18b843
< Strict-Transport-Security: max-age=31536000
< X-FRAME-OPTIONS: SAMEORIGIN
< x-ms-suspended-features: features=""
< X-Powered-By: ASP.NET
< MicrosoftSharePointTeamServices: 16.0.0.6413
< X-Content-Type-Options: nosniff
< X-MS-InvokeApp: 1; RequireReadOnly
< X-MSEdge-Ref: Ref A: 4A6D4FE3B7494A589915F680E32C91DD Ref B: CH1EDGE0521 Ref C: Tue Apr 25 14:30:48 2017 PST
< Date: Tue, 25 Apr 2017 21:30:47 GMT
* HTTP error before end of send, stop sending
<
This is happening consistently with different admin tokens and for different tenants and admin accounts. Has anything changed that might only be affecting ODB with admin tokens?
About this issue
- Original URL
- State: closed
- Created 7 years ago
- Reactions: 2
- Comments: 45 (17 by maintainers)
The patch should be, for all intents and purposes, fully deployed. Can anyone that was having this issue ( @dluces @amagliul @ad2012 ) please try again and confirm we’ve resolved the issue?
I can also confirm that this has resolved the issue for us. Great work @ificator! I really appreciate the swift resolution.
@ificator Same here, it seems to be working now. We have about 10 tests for filenames with UTF-8 characters that were failing before and are passing now. Thank you!
Tried it successfully 👍 Thank you very much! Great work, fast fix 🥇
This is the received uploadUri:
It looks like .NETs
Uriclass will auto encode%uXXXXto%25uXXXXso this may be pretty hard to work around on the clients side (at least for .NET). I’m going to push a code change now and see if we can fast track deployment.We are seeing the same issue that @dluces is describing above where filenames with non-ASCII characters will generate a 401 exception when attempting an upload.
For example, trying to upload a file with the name
ä.jpgin the root of a user’s drive will produce a 401 response with error message: “This access token is not valid on this endpoint.”Hello @ificator
I might be seeing this issue happening again since Friday at about 4pm MT. The upload URL does not contain
access_tokenorprooftokenanymore. Instead, it now has atempauthparameter that seems to be a valid JWT. However, the URL is about 1178 characters long with this parameter, so I’m guessing it’s pushing the URL over the limit.I’ve tried removing this parameter and putting it in the Authorization header without luck. I’ve tried removing this parameter and using the regular access token (the one used to create the upload session) and it did not work either. I’ve tried just removing the parameter and of course that didn’t work.
Also, this doesn’t break our tests for regular filenames but only for filenames with UTF-8 characters in them, which become way longer when URL-encoding them. This can potentially push the limit for the URL.
This is how the payload of the JWT in the
tempauthparameter looks:Any ideas? Workaround?
I just wanted to update you guys on a couple of things.
Be aware that the work done for item 2 above will change the structure of the URLs, and so if you’re utilizing the work around we discussed earlier you’ll want to make sure it’s resilient (e.g. only do it when you see both the access_token and prooftoken query string parameters)
@desmondyeung did you also include the
X-PROOF_TOKENheader?@dluces shouldn’t be related to this thread so go ahead and create a new issue and we’ll investigate
Update:
A few months ago I remember a similar issue happening. MS acknowledged it and fixed it. However, they provided a workaround: to remove the
Authorizationheader when uploading into the upload URL. This workaround does NOT work this time, as doing that just returns404 Not Foundinstead.Great report. If it’s helpful, here another example request/response:
I’m observing the same behavior using app-tokens for ODB. Started happening in the last week or so.