You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In vite.config.ts, when v3_singleFetch is set to true, there should be no errors with the Content Security Policy header.
Actual Behavior
The browser console shows this error when visiting the index route:
Refused to execute inline script because it violates the following Content Security Policy directive: "script-src 'nonce-my_nonce' 'strict-dynamic'". Either the 'unsafe-inline' keyword, a hash ('sha256-kFFCt2bRik8XnhrWeg2mf+46osExdawZhbMUaEMGnYk='), or a nonce ('nonce-...') is required to enable inline execution.
If you click the link on the browser console error, it shows that the error is ocurring when calling import("/app/entry.client.tsx");. The script tag that calls import() does have the correct nonce attribute on it, but the error happens anyway. Not sure if this is relevant but just thought I'd mention it.
At the index route, there is a simple counter with a button to increment the count using react state. There is also a script tag below that which is supposed to cause an error, because it is missing a nonce attribute. (Just to prove that CSP is working. Feel free to remove this script if it's getting in the way of debugging.)
If you set v3_singleFetch to false, and then visit the index route, the counter works, and the script without a nonce doesn't, which is expected. If you set v3_singleFetch to true, and then visit the index route, the counter does not work, and an error is shown in the console, which is not expected.
As far as I can tell, the reproduction is following the advice from the docs regarding CSP:
Finally, what’s missing from the docs, is that renderToPipeableStream also accepts nonce as a second parameter. As suggested by this StackOverflow answer or in this comment on an older issue. This resolved the issue on my end.
Looks like I forgot to include the nonce prop on <RemixServer />. I guess I assumed passing the nonce in the 2nd arg of renderToPipeableStream would have been enough, but you have to do it in both places.
Thanks Bart!
It's probably a good idea to open that issue about the docs. It would be great if the docs had all these steps for CSP in one place for easy viewing.
Reproduction
StackBlitz reproduction: https://stackblitz.com/~/github.com/ReidCole/remix-singlefetch-csp
System Info
Used Package Manager
npm
Expected Behavior
In vite.config.ts, when
v3_singleFetch
is set totrue
, there should be no errors with the Content Security Policy header.Actual Behavior
The browser console shows this error when visiting the index route:
Refused to execute inline script because it violates the following Content Security Policy directive: "script-src 'nonce-my_nonce' 'strict-dynamic'". Either the 'unsafe-inline' keyword, a hash ('sha256-kFFCt2bRik8XnhrWeg2mf+46osExdawZhbMUaEMGnYk='), or a nonce ('nonce-...') is required to enable inline execution.
If you click the link on the browser console error, it shows that the error is ocurring when calling
import("/app/entry.client.tsx");
. The script tag that callsimport()
does have the correct nonce attribute on it, but the error happens anyway. Not sure if this is relevant but just thought I'd mention it.At the index route, there is a simple counter with a button to increment the count using react state. There is also a script tag below that which is supposed to cause an error, because it is missing a nonce attribute. (Just to prove that CSP is working. Feel free to remove this script if it's getting in the way of debugging.)
If you set
v3_singleFetch
tofalse
, and then visit the index route, the counter works, and the script without a nonce doesn't, which is expected. If you setv3_singleFetch
totrue
, and then visit the index route, the counter does not work, and an error is shown in the console, which is not expected.As far as I can tell, the reproduction is following the advice from the docs regarding CSP:
It's possible I missed something though. Any help is greatly appreciated.
The text was updated successfully, but these errors were encountered: