@Alex, not sure if my issue relates:

I'm receiving Network.requestIntercepted events but not with AuthChallenge like it should when I visit a page that requires HTTP authentication. I've tested on Windows and Linux (Ubuntu)

Right, I forgot to mention this detail in my original report: in my case the first intercepted request contained proxy basic authentication (hence I was not able to see any other request).

In --headless mode all events fire as expected and thus I'm able to provide the authChallengeResponse; however, if I comment out the --headless flag, then spawned tab displays a proxy auth popup and *no* Network.requestIntercepted are fired (even if I answer the auth challenge manually in popup).

And, as described in the issue, removing the --user-data-dir seems to resolve the issue.

@brois.ok...@ub.io

I am trying to get the authChallenge to work. Could you please let me know what platform you are running it in and the version of Chromium you are using?

Also, are you using any other flags? Thanks.

I'm on Mac OS X 10.11.6, Chrome Version 62.0.3175.0 (Official Build) canary (64-bit).

I tried with variety of flags, but the minimal set to reproduce the issue is:

--remote-debugging-port
--proxy-server
--user-data-dir=/some/path  // works without it

Also, in --headless the event fires regardless of --user-data-dir.

@boris.ok...
Thanks for the information. 

@alexclarke
You mentioned that Linux is not affected? Do you mean that Network.requestIntercepted worked for you with authChallenge on a Linux machine? Thanks

It really should work on all platforms (the net stack is cross platform). We have a layout test for this - using a pretty simplistic script:

https://cs.chromium.org/chromium/src/third_party/WebKit/LayoutTests/http/tests/inspector-protocol/network/resources/unauthorised.pl?type=cs&q=inspector-protocol/network/resources/unauthorised.pl&l=1

https://cs.chromium.org/chromium/src/third_party/WebKit/LayoutTests/http/tests/inspector-protocol/network/interception-auth-provide-credentials.js?type=cs&q=interception-auth-provide-credentials.js&l=1

Thanks for the response alexclarke. I have a separate ticket on the issue I'm experiencing and it would be great to have your input there as well(so we don't get too off topic here). I'll take a look at those two links you posted. I'm using Python with the websocket-client module. Would that affect receiving the requestIntercepted API? (and specifically authChallenge ones since I'm able to receive other types of requestIntercepted)

My ticket on the linux issue: https://bugs.chromium.org/p/chromium/issues/detail?id=752195#c_ts1502093743

It's possible there's a bug in our handling of authChallenges but things like the websocket library shouldn't make any difference.  Do any devtools commands your for you?

Yes, other devtool commands work fine for me (both sending API methods and receiving events are good). Receiving requestIntercepted event with authChallenge is the only thing I'm having issues with.

Thank you for your time guys!

I've stitched together a repo to reproduce the issue: https://github.com/inca/cdp-request-intercept — and you'll also find a video demo in README.

Out of curiosity if you visit chrome://policy is there anything there with Auth or Profile in its name?  If so that would explain why --headless makes a difference, headless mode doesn't support chromed device policies.

I say would explain, but I mean might explain :)

No Policies are set in my case (actually, it's a fresh install of Chrome Canary on Mac via official distributable).

I don't believe this issue is related to AuthChallenge in any way, even though my initial tests were using proxy with basic auth — but I've discovered that it's unrelated to the `--user-data-dir` bug I'm currently experiencing (https://www.youtube.com/watch?v=IqhRD5qU0EE — no Network.requestIntercepted are fired at all when using a fresh --user-data-dir and non-headless mode).

OK thanks for the report.  I'm currently patching our office mac and will try to reproduce this locally.

I build a tip of tree chromium on a mac and tried to reproduce these issues.

In a terminal I ran:

rm -rf /tmp/foobar
./Chromium --remote-debugging-port=8888 --user-data-dir=/tmp/foobar

In another chrome in devtools console I ran:

var exampleSocket = new WebSocket("ws://localhost:8888/devtools/page/CURRENT HASH");
exampleSocket.onopen = function (event) {
	exampleSocket.send('{"id": 1, "method": "Network.enable", "params": {}}');
	exampleSocket.send('{"id": 2, "method": "Network.setRequestInterceptionEnabled", "params": { "enabled": true}}');
};
var id = 3;
exampleSocket.onmessage = function(event) {
  var message = JSON.parse(event.data);
  
  if (message.method == "Network.requestIntercepted") {
    this.send(JSON.stringify({"id": id++, "method": "Network.continueInterceptedRequest", "params": {"interceptionId":  message.params.interceptionId}}));
    console.log(event.data);
    return;
  }
};

In the ToT chrome I navigated to example.com (and also github.com) and I saw the expected Network.requestIntercepted requests. 

I then visited https://www.httpwatch.com/httpgallery/authentication/ and clicked the blue Display Image button and saw this intercepted request.

{"method":"Network.requestIntercepted","params":{"interceptionId":"id-57","request":{"url":"https://www.httpwatch.com/httpgallery/authentication/authenticatedimage/default.aspx?0.013928345730789271","method":"GET","headers":{"User-Agent":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3180.0 Safari/537.36","X-DevTools-Emulate-Network-Conditions-Client-Id":"cdb8b629-5916-42df-a472-619d88521d2a","Accept":"image/webp,image/apng,image/*,*/*;q=0.8"},"initialPriority":"Low","referrerPolicy":"no-referrer-when-downgrade"},"resourceType":"Image","isNavigationRequest":false,"authChallenge":{"source":"Server","origin":"https://www.httpwatch.com","scheme":"basic","realm":"Login with a user name of httpwatch and a different password each time"}}}

This is very strange! I can only think there must be some device policy or something of that nature that's preventing these this from working for you.

Incidentally the --headless mode  quite substantially changes what is run, the entire chrome/ layer from the source code is gone (including things like device policies, extensions, profile sync and so on).

Strange indeed. I also noticed you're using a static path /tmp/foobar. In my tests I'm using a fresh dir each time (with Math.random() in it), so just curious whether it still works for you with a non-existent directory?

Doesn't seem to make any difference.  I also tried paths outside /tmp, in each case interception worked.

As component is already added hence adding 'TE-NeedsTriageHelp' to move this out of TE Unconfirmed triaging bucket.

Issue has not been modified or commented on in the last 365 days, please re-open or file a new bug if this is still an issue.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot