Bug 253696

Summary: declarativeNetRequest modifyHeaders doesn't work for fetch requests initiated from the same Safari extension
Product: WebKit Reporter: vsr4493
Component: WebKit ExtensionsAssignee: 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:    

Description vsr4493 2023-03-10 02:07:29 PST
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
Comment 1 Radar WebKit Bug Importer 2023-03-17 03:08:14 PDT
<rdar://problem/106851279>
Comment 2 vsr4493 2023-05-22 07:09:14 PDT
Bump! 


Summary: Consider allowing header modification (specifically the origin) using declarativeNetRequest modifyHeaders for fetch requests made by the extension.
Comment 3 Karl Dubost 2023-11-06 19:02:04 PST
Thanks for the report, probably a duplicate of

*** This bug has been marked as a duplicate of bug 246493 ***
Comment 4 Karl Dubost 2023-11-06 19:49:21 PST
*** Bug 263818 has been marked as a duplicate of this bug. ***
Comment 5 Karl Dubost 2023-11-06 19:51:10 PST
I'm changing the resolution as declarativeNetRequest has been released but some of its features are not implemented.
Comment 6 Nicholas Lim 2023-11-13 06:16:29 PST
Hi, may I know if there is a tracker for progress on the declarativeNetRequest API? Thanks!
Comment 7 Gabriel Aubut-Lussier 2024-02-13 13:30:19 PST
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.