DNR: unique/opaque initiator is not handled correctly |
|||
Issue description
Repro steps:
1) Load extension with the following ruleset:
[
{
"id" : 1,
"action": { "type" : "block" },
"condition" : {"urlFilter" : "google.com", "resourceTypes" : ["main_frame"] }
}
]
2) Visit google.com. See the page is blocked temporarily but the navigation ultimately succeeds.
Reason: DNR requires host access to both request url and initiator. Main frame navigations can have an opaque initiator, causing the extension to not have access to the request.
,
Sep 27
,
Sep 28
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/5f769f77d4053c9a854078ee451e0410feff4a4f commit 5f769f77d4053c9a854078ee451e0410feff4a4f Author: Karan Bhatia <karandeepb@chromium.org> Date: Fri Sep 28 00:40:09 2018 DNR: Handle opaque origin correctly while checking access to initiator. Declarative Net Request API requires extensions to have access to both the request url and initiator to block/redirect a request. Currently any requests with an opaque origin as the initiator can't be intercepted by extensions. Correct this. BUG= 889713 Change-Id: Ie86bf745da652d6f076e9d3076e06ec0c202f4d1 Reviewed-on: https://chromium-review.googlesource.com/1248541 Commit-Queue: Karan Bhatia <karandeepb@chromium.org> Reviewed-by: Istiaque Ahmed <lazyboy@chromium.org> Cr-Commit-Position: refs/heads/master@{#594933} [modify] https://crrev.com/5f769f77d4053c9a854078ee451e0410feff4a4f/chrome/browser/extensions/api/declarative_net_request/ruleset_manager_unittest.cc [modify] https://crrev.com/5f769f77d4053c9a854078ee451e0410feff4a4f/extensions/browser/api/web_request/web_request_permissions.cc
,
Sep 28
|
|||
►
Sign in to add a comment |
|||
Comment 1 by karandeepb@chromium.org
, Sep 27