it appears that onAuthRequired handler is not fired for chrome://chrome-signin page.
Reported by
rglee...@londontrustmedia.com,
Feb 27 2017
|
||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36 Steps to reproduce the problem: 1. Create a new extension 2. Configure a HTTPS proxy to use via extension API, proxy must require authentication. 3. Add an onAuthRequired listener, which sends username + password. 4. Visit chrome://chrome-signin/?access_point=6&reason=0 What is the expected behavior? The expected behaviour is that the extension manages authentication through onAuthRequired, and a browser dialog asking for credentials never appears. What went wrong? a HTTP basic auth dialog appears when opening chrome://chrome-signin/?access_point=6&reason=0. instead it should use onAuthRequired listener and not show any basic auth dialog. Did this work before? N/A Does this work in other browsers? N/A Chrome version: 56.0.2924.87 Channel: stable OS Version: OS X 10.12.3 Flash Version: i realise this is hard to reproduce, and requires access to a HTTPS proxy configured to use authentication. if, i can in anyway help reproduce, please let me know. I observed that onAuthRequired is never triggered, but i do not know why.
,
Feb 27 2017
maybe the easiest way to reproduce this issue is to try with one of the popular, and free proxy extensions, such as Tunnelbear. I can reproduce the bug with that extension, and my own.
,
Feb 28 2017
,
Mar 1 2017
,
Mar 3 2017
Which API are you using? Assuming it's the webRequest API (and you're referring to https://developer.chrome.com/extensions/webRequest#event-onAuthRequired), this is pretty much WAI. We don't allow extensions to intercept any communication from a chrome:// url by design.
,
Mar 4 2017
Yeah, I am using the webRequest.onAuthRequired API. The behaviour is still odd. I don't think showing the dialog makes sense. In my case authentication is managed by an extension. Is there a way to solve this without showing an auth dialog box, i wonder why one is needed for a chrome:// URL? I always assumed those were local pages?
,
Mar 17 2017
chrome:// urls are considered secure pages, and we don't really let extensions act on them. It's true that there are some chrome pages that are relatively innocuous, and letting an extension run or modify requests for isn't an issue, but we don't really want to relax the restriction (since it creates another potential attack vector). Unfortunately, I don't see us letting anyone intercept events from chrome:// pages any time soon. Sorry I couldn't be more help!
,
Mar 18 2017
Hey - thanks for the reply. That's okay. I just wonder if somehow the user experience could be better. Imagine an extension that controls proxy settings for you (including authentication) that works fine until you visit chrome:// page. i think in that scenario the HTTP basic authentication dialog that appears is confusing. I'm not sure of a better behaviour.. Sorry. Thanks for the reply, and all the cool work on Chrome! |
||||
►
Sign in to add a comment |
||||
Comment 1 by a...@chromium.org
, Feb 27 2017Labels: -OS-Mac OS-All
Owner: rdevlin....@chromium.org