Option to use devtools with csp #18140
Conversation
|
This pull request is automatically built and testable in CodeSandbox. To see build info of the built libraries, click here or the icon next to each commit SHA. Latest deployment of this branch, based on commit 9ffef21:
|
|
Can we link to some way for the person to verify the hash actually matches our code? |
There is some problem with it, because the code is being constructed from different pieces concatenated together: . If I include the reference to this line to the README, it still gives nothing to the users, because they cannot just see the code which was used to generate the hash.We may also try to generate the global hook code string at the build time, and then import and use it... This way it will be easier to refer to it. What do you think? |
This was the concern I raised. It looks like the hook source changes pretty infrequently, but we are unlikely to remember to update a README like this if we change it down the road. Option 1: ReactJS.orgMaybe we could store the hash at build time like @ruslan-shuster says, and add an endpoint to reactjs.org that pulls it from GitHub (like it pulls the error codes) and displays some copy-pasteable thing for people to add? We'd still have to remember to update reactjs.org to do this, but that probably gets updated enough on its own that the window of time when the two were out of sync wouldn't be too big. Option 2: READMEThere's also the fact that rollouts to different browser stores take wildly different times. Firefox usually approves new extensions within minutes, where as Chrome now takes weeks. (So if we changed the hook, there would be a period of time when our messaging would be wrong one way or another.) We could have the README show different hashes by versions. If we stored the most recently built-and-published hash, then the DevTools build script could print a big bold reminder (if it ever changes) letting person know to add a new entry to the README. Option 3: Add the hash to DevTools setting UIDevTools settings UI currently shows the revision it was built from inline: We could add another section that shows the CSP hash needed. Then our README could just say "look at DevTools to find the hash you should add for the current version". That way, at least, we could just auto-update this value anytime we build and release a new version (and we'd never have to remember to update external documentation). I think option 3 seems the most promising. What do you think? |
|
@bvaughn the third one indeed seems the most elegant and convenient. I'll start working on it and see how it looks. I think I should use some crypto library to generate sha256, since JS does not have such functionality in the standard library. Do you have any preferences on this one? Maybe Facebook has something open-sourced? |
|
Cool. Thanks @ruslan-shuster. I think Node's built-in |
|
Thanks @bvaughn, it might work! The only problem is that the hook resides in the As I understand it, we need to import the hook code from injectGlobalHook at the build stage, generate a hash and export it as a 'process.env.GLOBAL_HOOK_HASH', so that we can use it just the same as build version. |
|
Sorry @ruslan-shuster, I missed this comment somehow.
That sounds right to me. Our build script already does this and stores the artifact at e.g. Can we just use that? 😄 |
|
@bvaughn I don't see the way how we could use it from the packages/react-devtools-extensions/webpack.config.js. We cannot import the file you've mentioned for two reasons:
I assume that the variable holding the code of the hook will reside packages/react-devtools-extensions/src/injectGlobalHook.js, and should be somehow imported at the build phase from here. |
Why can't we run part of the build twice? (Or split it into steps?) Unfortunately I don't have time to dig into this and think about it right now. Too much context switching 😦 I'm sorry! |
|
This pull request has been automatically marked as stale. If this pull request is still relevant, please leave any comment (for example, "bump"), and we'll keep it open. We are sorry that we haven't been able to prioritize reviewing it yet. Your contribution is very much appreciated. |
|
Closing this pull request after a prolonged period of inactivity. If this issue is still present in the latest release, please ask for this pull request to be reopened. Thank you! |
Summary
Currently, REACT_DEVTOOLS_GLOBAL_HOOK is being injected to the window through adding <script> tag to the web page, since it's the easiest cross-platform way to interact with web page environment. However, there are some users who restrict possible sources for scripts via Content Security Policy, but still want their web page to interact with
react-devtools. The solution proposed here uses the possibility to whitelist webhook mounting script by its hash (see more here). Solves the issue described here.