256054 2023-04-27 12:56:29 -0700 Redirection to page in extension with regexSubstitution is blocked 2023-09-08 10:10:41 -0700 1 1 1 Unclassified WebKit WebKit Extensions Safari Technology Preview Unspecified Unspecified NEW InRadar P2 Normal --- 1 emond.papegaaij webkit-unassigned achristensen luke.selker timothy webkit-bug-importer oldest_to_newest 1951633 0 emond.papegaaij 2023-04-27 12:56:29 -0700 When using the declarativeNetRequest like this: const EXT_PAGE = chrome.runtime.getURL('/callback.html'); const RULE = { id: 1, condition: { regexFilter: '^https://www\.topicus-keyhub\.com/browser-extension-callback\.html.+$', resourceTypes: ['main_frame'] }, action: { type: 'redirect', redirect: { regexSubstitution: EXT_PAGE + '#\\0' } } }; chrome.declarativeNetRequest.updateDynamicRules({ removeRuleIds: [RULE.id], addRules: [RULE], }); The request to the URI matched with the regex is intercepted, but the redirection fails with the following message: Safari can’t open the page “safari-web-extension://5107FF07-6DB1-4907-BCAB-D84EB6E2655E/callback.html#https://www.topicus-keyhub.com/browser-extension-callback.html?iss=https://test.topicus-keyhub.com&state=4ca2b81ed761555f4b9dad97c9d47f9ef6af239d507143b088dc32e8174a1144&error=interaction_required&error_description=User+interaction+required”. The error is: “Redirection to URL with a scheme that is not HTTP(S)” (:0) We are using this method of redirection to intercept the original URI to complete an OAuth2 code flow. The intercepted page is a stub landing page and only used as a fixed redirection URI for the OAuth2 flow. 1952981 1 webkit-bug-importer 2023-05-04 12:57:30 -0700 <rdar://problem/108908609> 1976427 2 luke.selker 2023-09-08 07:42:59 -0700 Hi, Just checking if there's been any update on this bug? It looks there may need to be a modification to this code here? https://bugs.webkit.org/show_bug.cgi?id=256054 I'd really like to provide an update to our customers on when they can expect SSO to be functional in Safari. Thanks! 1976437 3 emond.papegaaij 2023-09-08 08:32:35 -0700 We've implemented a fallback to the old webRequest API for Safari. This also required us switch to manifest v2, because the webRequest API cannot be used with a non-persistent background page and v3 no longer supports persistent background pages. I think the issue with the redirect may have to do with Safari not supporting web_accessible_resources: https://bugs.webkit.org/show_bug.cgi?id=246489 All this is getting quite a mess to get right on all browsers. This is what we ended up using: - declarativeNetRequest wit manifest v3 on all Chromium based browsers - webRequest with manifest v3 on Firefox - webRequest with manifest v2 on Safari 1976458 4 luke.selker 2023-09-08 10:10:41 -0700 Thanks for the quick response! Unfortunately we were using Blocking WebRequest which isn't supported in Safari, so we had not choice but to implement using DeclarativeNetRequest. Unless I'm wrong, I don't think we can use both WebRequest and DeclarativeNetRequest at the same time