-
-
Notifications
You must be signed in to change notification settings - Fork 4.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: provide a workaround for unsafe-inline
CSP that also works in Safari
#7800
fix: provide a workaround for unsafe-inline
CSP that also works in Safari
#7800
Conversation
unsafe-inline
CSP that also works in Safariunsafe-inline
CSP that also works in Safari
Have you tried explicitly assigning it an empty string? Maybe Safari treats it as |
@schuetzm nope, that does not appear to work. I suspect the Safari bug is later in the process maybe? Regardless, it chokes just as happily when explicitly setting the |
42e2e27
to
da5ddd4
Compare
unsafe-inline
CSP that also works in Safariunsafe-inline
CSP that also works in Safari
To be conservative, I will add this to the 4.x milestone |
@dummdidumm is attempting to deploy a commit to the Svelte Team on Vercel. A member of the Team first needs to authorize it. |
Before submitting the PR, please make sure you do the following
[feat]
,[fix]
,[chore]
, or[docs]
.Tests
npm test
and lint the project withnpm run lint
Ref #6662.
Currently, CSS transitions require
style-src: unsafe-inline
CSP. There is almost a workaround, but it doesn't work in Safari (and iOS<15). This fixes that workaround to also work in Safari.This changes the inserted style element for transitions to initially include the string
'/* empty */'
. This allows you to work around requiringunsafe-inline
CSP discussed in #6662 by adding a hash to your CSP:Using the hash of the empty string,
'sha256-47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU='
, works fine in most browsers, but Safari for some reason thinks the empty string should have a different hash.Users currently using the empty string hash (like me) will have their apps break from this, but it currently only half works anyway so I don't think that's a big deal.
As @Rich-Harris has said this isn't very elegant, and the eventual solution is to use the Web Animations API instead, but I'd still like for this to work on iOS in the mean time :)