-
-
Notifications
You must be signed in to change notification settings - Fork 83
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
Verify feature detection message #369
Verify feature detection message #369
Conversation
Hmm... Looks like we have a test failure for Firefox 67.0. Not sure if it's a flake or a real failure (can't seem to trigger a retry from my side). |
supportsImportMeta = data[1]; | ||
supportsCssAssertions = data[2]; | ||
supportsJsonAssertions = data[3]; | ||
const isFeatureDetectionMessage = Array.isArray(data) && data[0] === 'esms' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could potentially make this a bit more resistant to forgery by generating some random bytes instead of this hardcoded string. But I don't see what a potential attacker has to gain by taking over feature detection, so there might not be a need?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed, we don't need to be forge resistant.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for working this one out. I tend to agree it seems more likely security blocking would block the messaging entirely, as opposed to passing primitives, so I'm happy to land this under that assumption.
supportsImportMeta = data[1]; | ||
supportsCssAssertions = data[2]; | ||
supportsJsonAssertions = data[3]; | ||
const isFeatureDetectionMessage = Array.isArray(data) && data[0] === 'esms' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed, we don't need to be forge resistant.
I was also running into intermittent feature detection failures similar to the ones mentioned in #368 once I upgraded to 1.7.1 on https://reflame.app, so I made a custom build with some additional logging on the message callback function and found a pretty big clue:
Looks like the root of the issue might be that we're not verifying the source of the message, so anything that calls postMessage before es-module-shims (in this case the react dev tools extension) can cause feature detection to fail, often non-deterministically due to races.
Looking at this previous related issue, I think this is the more likely cause for that one too rather than some security policy (i.e. something on the page called postMessage with
undefined
as the message). So I removed the previous branch where we continue to resolve feature detection even after failing validation, and instead opting to return early and wait for the next message. WDYT?Also, I added the debug build as an exported module so it can be accessed from the npm package as well.