| Summary: | Redirection to page in extension with regexSubstitution is blocked | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Emond Papegaaij <emond.papegaaij> |
| Component: | WebKit Extensions | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW --- | ||
| Severity: | Normal | CC: | achristensen, luke.selker, timothy, webkit-bug-importer |
| Priority: | P2 | Keywords: | InRadar |
| Version: | Safari Technology Preview | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
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! 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 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 |
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.