Bug 253696
Summary: | declarativeNetRequest modifyHeaders doesn't work for fetch requests initiated from the same Safari extension | ||
---|---|---|---|
Product: | WebKit | Reporter: | vsr4493 |
Component: | WebKit Extensions | Assignee: | Nobody <webkit-unassigned> |
Status: | REOPENED | ||
Severity: | Normal | CC: | gaubut, guivr2011, jan, karlcow, niclimcongyi, timothy, webkit-bug-importer |
Priority: | P2 | Keywords: | InRadar |
Version: | Safari Technology Preview | ||
Hardware: | All | ||
OS: | All | ||
Bug Depends on: | 246493 | ||
Bug Blocks: |
vsr4493
ModifyHeaders in declarativeNetRequest does not work for fetch requests from the extension.
This might be since the extension does not have permission over the safari-extension://GUID/ origin which is reset on every browser launch.
Expected behaviour:
The extension should have permissions for its own origin by default and should be able to modify headers for requests initiated from its own background page.
As such adding a rule like this should work:
browser.declarativeNetRequest.updateDynamicRules({
addRules: [{
"id": 1,
"priority": 1,
"action": {
"type": "modifyHeaders",
"requestHeaders": [{"header": "origin", "operation": "set", "value": "https://www.bar.com"}]
},
"condition": {
"urlFilter": "http://foo.com", // Any URL that the extension has permissions for
"resourceTypes": ["main_frame", "xmlhttprequest"]
}
}],
})
Current behaviour:
The rule currently does not work
Attachments | ||
---|---|---|
Add attachment proposed patch, testcase, etc. |
Radar WebKit Bug Importer
<rdar://problem/106851279>
vsr4493
Bump!
Summary: Consider allowing header modification (specifically the origin) using declarativeNetRequest modifyHeaders for fetch requests made by the extension.
Karl Dubost
Thanks for the report, probably a duplicate of
*** This bug has been marked as a duplicate of bug 246493 ***
Karl Dubost
*** Bug 263818 has been marked as a duplicate of this bug. ***
Karl Dubost
I'm changing the resolution as declarativeNetRequest has been released but some of its features are not implemented.
Nicholas Lim
Hi, may I know if there is a tracker for progress on the declarativeNetRequest API? Thanks!
Gabriel Aubut-Lussier
I would like to add that websocket connections are also affected by this current limitation. Assuming the resourceTypes also include "websocket", I would expect a `new WebSocket("wss://example.com");` to match against the rule and be modified accordingly.