Authorization Failed - Authorization header not sent
Reported by
julianca...@gmail.com,
Mar 23 2017
|
||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36 Example URL: Steps to reproduce the problem: 1. Login into a website, which uses an authorization header to communicate to a microservice to download files 2. request to download a file, (authorization header sent with the request) 3. File sent back (using send_file by Flask) 4. Chrome seems to send another request to the microservice, without the Authorization header. What is the expected behavior? 1. Login 2. Send request 3. Response sent 4. Get file (chrome doesn't send another request?) OR 1. Login 2. Send request 3. Response sent back using send_file 4. Chrome sends request with Authorization header What went wrong? As I understand the problem; which is getting 'Authorization Failed' from inside chrome, but not through Postman; the problem is that the browser seems to send an additional request on initiation of the download; even though the file has been sent back from the microservice. Yes, the request to get the file is sent via XHR/Ajax. Did this work before? No Chrome version: 53.0.2785.143 Channel: n/a OS Version: 16.04 Flash Version: Shockwave Flash 25.0 r0
,
Mar 24 2017
I'm not sure if that's what you need, do you require something else (not the save file thing) ?
,
Mar 24 2017
Thank you for providing more feedback. Adding requester "rch@chromium.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Mar 24 2017
I'll try to trace another time since that file didn't contain it, I think.
,
Mar 24 2017
Correct, that trace file doesn't look to contain an aborted download. It just has a couple requests to Google domains, nothing that you're likely to have tried to download.
,
Mar 27 2017
,
Mar 27 2017
Thank you for providing more feedback. Adding requester "mmenke@chromium.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Mar 27 2017
Server is sending us a 401 for reasons which I don't think anyone can determine other than the server operator. We send a request with cookies, it returns 401, its reasoning is inscrutable from the log. It may be because we aren't sending an origin header, though I believe that's expected from an <a download> link. There are other requests for the same URL in two different contexts that it does let through (One is a CORS request, not sure what the other one is). Anyhow, if this is a Chrome bug (Something I'm not yet convinced of), doesn't seem to lie with the network stack - may be the downloads system, or something to do with the headers we set. Could you tell us what your server expects from a request before returning a 401? Here are the headers we send (Other than the host header and path for the GET) Connection: keep-alive User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36 Accept-Encoding: gzip, deflate, sdch, br Accept-Language: en-GB,en-US;q=0.8,en;q=0.6 Cookie: [460 bytes were stripped]
,
Apr 11 2017
Probably not blink>loader.
,
Apr 11 2017
Makes sense, alright, I'll try to go through our side of things. - Thanks for the help.
,
Apr 11 2017
Thank you for providing more feedback. Adding requester "mmenke@chromium.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Apr 12 2017
,
Apr 20 2017
|
||||||||||
►
Sign in to add a comment |
||||||||||
Comment 1 by rch@chromium.org
, Mar 23 2017