Hi, I'd like to report a bug in the OAuth HTTP handshake. Included below are the request/response sequence as reported by Fiddler. Note that I am redirecting to a URL which requires authentication. Note that in the PowerQuery handshake that the third request is sent to the original URL instead of to the correct redirect URL, and results in an endless loop of asking for authentication. Compare that to the sequence done by a browser. The third request which include the authentication header is sent to the redirect URL and succeeds. Demonstration A: Sequence when using OAuth in Power Query ============================================================= 1. GET /odata/Aql2OData HTTP/1.1 Authorization: Basic c3A6M0loT3RuQ3lkRzJuQVVWZWFhe... HTTP/1.1 302 Found Location: /odata/c4e6baed-efc1-457d-a3dc-32b47a5a5a94/Aql2OData ------------- 2. GET /odata/c4e6baed-efc1-457d-a3dc-32b47a5a5a94/Aql2OData HTTP/1.1 HTTP/1.1 401 Unauthorized ------------- 3. GET /odata/Aql2OData HTTP/1.1 Authorization: Basic c3A6M0loT3RuQ3lkRzJuQVVWZWFhe... HTTP/1.1 302 Found Location: /odata/86247d7c-7417-4b47-a17f-8ee1644cfc02/Aql2OData -------------------------- 4. GET /odata/86247d7c-7417-4b47-a17f-8ee1644cfc02/Aql2OData HTTP/1.1 HTTP/1.1 401 Unauthorized Demonstration B: Sequence when using Internet Explorer ============================================================= 1. GET /odata/Aql2OData HTTP/1.1 Authorization: Basic c3A6M0loT3RuQ3lkRzJuQVVWZWFhe... HTTP/1.1 302 Found Location: /odata/c4e6baed-efc1-457d-a3dc-32b47a5a5a94/Aql2OData ------------- 2. GET /odata/c4e6baed-efc1-457d-a3dc-32b47a5a5a94/Aql2OData HTTP/1.1 HTTP/1.1 401 Unauthorized ------------- 3. GET /odata/c4e6baed-efc1-457d-a3dc-32b47a5a5a94/Aql2OData HTTP/1.1 Authorization: Basic c3A6M0loT3RuQ3lkRzJuQVVWZWFhe... HTTP/1.1 200 OK
EDIT: The response from Microsoft is that this is a bug, but not the one I was thinking. I had expected a trace like that in Demonstration B when using Power Query. But in Power Query there exists state, in the form of the value pasted into the OData URL field, which doesn't exist in the browser handshake. What Microsoft pointed out is that calls #2 and #4 should also have included the authentication header - that is a bug.
For my work I have abandoned the redirect approach for now and will instead script the OAuth request and include a random GUID in the URL which will uniquely scope the metadata to that particular request. I have to script the call anyway in order to be able to pass in workbook-scoped parameters.
No comments:
Post a Comment