[enh] allow safari-web-extension CORS preflight - refs #49 - #692
Conversation
Safari still preflights JSON/token requests from the popup. Answer OPTIONS and skip CSRF on the same extension API surface Chrome and Firefox already use, including /api/history.
|
Thanks for your contribution. @nburns could you help verifying the issue/solution? |
|
I hope to be a long term contributor on here as i have interest in Hister and supporting its compatibility on Safari as an avid Safari user myself please let me know if anything goes wrong / if I did. |
| h := w.Header() | ||
| h.Set("Access-Control-Allow-Origin", origin) | ||
| h.Set("Access-Control-Allow-Methods", "GET, HEAD, POST, OPTIONS") | ||
| h.Set("Access-Control-Allow-Headers", "Content-Type, X-Access-Token, X-Hister-Public, X-CSRF-Token, Authorization, Cookie") |
There was a problem hiding this comment.
ITT Cookie gets removed by the browser/cant be set from JS so we can remove this?
https://developer.mozilla.org/en-US/docs/Glossary/Forbidden_request_header
There was a problem hiding this comment.
Yea you're right, I'll get rid of it
Cookie is a forbidden request header in fetch; browsers never send it via Access-Control-Request-Headers, so listing it in Allow-Headers is unnecessary.
|
Thanks for both the review and the changes. Another issue: the fixed header allowlist breaks custom headers. The extension supports arbitrary headers for e.g. reverse proxy authentication, but the middleware permits only a fixed set in |
Safari lists the actual request headers in Access-Control-Request-Headers; echoing that list keeps user-configured reverse-proxy headers working instead of blocking anything outside a fixed allowlist.
3 participants
Safari's extension popup still sends a CORS preflight (
OPTIONS) for JSON bodies andX-Access-Token. Those requests currently fall through to the SPA handler, so token auth from the unofficial Safari extension fails even though CSRF already allowssafari-web-extension://origins on a subset of paths.This adds a small middleware that, only for trusted browser-extension origins on the extension API surface:
OPTIONSwith204Access-Control-Allow-*/api/historyas well (the content script posts search-result history there; Chrome/Firefox already share this origin check)Trusted origins are unchanged:
moz-extension://,safari-web-extension://, and the packaged Chrome extension id. Other origins are not given CORS headers.Test plan
go test ./server/ -run TestExtensionOPTIONS /api/addfrom asafari-web-extension://origin returns 204 withAccess-Control-Allow-Originset to that originOPTIONSfromhttps://evil.exampledoes not get those headersPOST /api/addandPOST /api/historyfrom the Safari origin succeed (201 / 200) with an access tokenAssistance: Cursor was used while writing the middleware and tests. The behaviour follows issue #49 and the earlier CORS POC in #46.