webRequest.onHeadersReceived is not triggered after authentication as stated in documentation
Reported by
rhour...@gmail.com,
Jan 24 2018
|
||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:52.0) Gecko/20100101 Firefox/52.0 Steps to reproduce the problem: 1. Load the attached extention in a chrome. 2. Navigate to https://httpbin.org/basic-auth/user/passwd (the auth test page, this can be changed to any page that needs authentication if you update the credentials in background.js) 3. Open the background console and find the logged messages from all the webRequest listeners and their order. What is the expected behavior? As per the documentation [1] in Life cycle of requests, the flow is expected to go to "onBeforeSendHeaders" after "onAuthRequired". However, this is definitely not the case. What concerns us the most is "onHeadersReceived" part as it's the only place to modify response headers as stated in the page [1] "onHeadersReceived(optionally synchronous) Fires each time that an HTTP(S) response header is received. Due to redirects and authentication requests this can happen multiple times per request. This event is intended to allow extensions to add, modify, and delete response headers, such as incoming Set-Cookie headers. The caching directives are processed before this event is triggered, so modifying headers such as Cache-Control has no influence on the browser's cache. It also allows you to cancel or redirect the request." [1] https://developer.chrome.com/extensions/webRequest#life_cycle What went wrong? The flow in the documentation is not correct. After "onAuthRequired" the only listener that is triggered is "onResponseStarted". Therefore, we are never reaching "onHeadersReceived" and not able to modify the response header for successful request. In my case, I don't want to modify response headers for responses with 401 status code and I expected that I'd be able to check the response headers after the request was successfully authenticated. Did this work before? N/A Does this work in other browsers? N/A Chrome version: 64.0.3282.113 (Official Build) beta (64-bit) (cohort: Beta) Channel: n/a OS Version: 10.0 Flash Version: Shockwave Flash 26.0 r0 If the documentation is correct then there's something wrong with these listeners and I provided a sample extension to test. If it's designed like this then please change the documentation and provide better explanation of the life cycle. A clear explanation of the handling workflow for requests with basic/digest authentication is missing here.
,
Jan 25 2018
,
Jan 25 2018
I've tested it with older chrome versions (back till chrome 48) and they all seem to behave the same without triggering onHeadersReceived after authentication.
,
Jan 30 2018
,
Feb 19 2018
Hi, could anybody take a look at this issue please? It's not clear how to track a webRequest when there's authentication. The API is behaving differently than what is stated in the documentation.
,
Apr 12 2018
Able to reproduce this issue on reported version 64.0.3282.113, on latest stable 65.0.3325.181, on latest beta 66.0.3359.81 and on latest canary 67.0.3394.0 using Windows 10,Mac 10.13.3 and Ubuntu 14.04. i.e; Output in console is same as screenshot attached above. This issue is seen from M-60. Hence considering this issue as Non-Regression and marking as Untriaged. Thanks!
,
Oct 30
the problem appears to be `ExtensionWebRequestEventRouter::GetAndSetSignaled` which will return false because the callbacks have already run for `kOnHeadersReceived`. Once you get past that I think `ExtensionWebRequestEventRouter::ExecuteDeltas` might also filter it out again if `new_url` or `override_response_headers` are set
,
Oct 30
diff --git a/extensions/browser/api/web_request/web_request_api.cc b/extensions/browser/api/web_request/web_request_api.cc
index ed7689d3b0b7..661fe769910d 100644
--- a/extensions/browser/api/web_request/web_request_api.cc
+++ b/extensions/browser/api/web_request/web_request_api.cc
@@ -1140,6 +1140,11 @@ ExtensionWebRequestEventRouter::OnAuthRequired(
const net::AuthChallengeInfo& auth_info,
net::NetworkDelegate::AuthCallback callback,
net::AuthCredentials* credentials) {
+
+ ClearSignaled(request->id, kOnBeforeSendHeaders);
+ ClearSignaled(request->id, kOnSendHeaders);
+ ClearSignaled(request->id, kOnHeadersReceived);
+
// No browser_context means that this is for authentication challenges in the
// system context. Skip in that case. Also skip sensitive requests.
if (!browser_context ||
,
Oct 30
the transaction will always be restarted when auth is required so clearing the events that happen from the start of the transaction fixes the issue |
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by rhour...@gmail.com
, Jan 24 201888.6 KB
88.6 KB View Download
58.3 KB
58.3 KB View Download