-
Notifications
You must be signed in to change notification settings - Fork 5k
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
Update the PhishingController to v2 and update phishing warning page #17835
Conversation
Socket Security Pull Request Report👍 No new dependency issues detected in pull request Pull request report summary
Bot CommandsTo ignore an alert, reply with a comment starting with Powered by socket.dev |
6e7b856
to
f712ac3
Compare
@@ -341,6 +356,22 @@ async function setupMocking(server, testSpecificMock) { | |||
}); | |||
|
|||
testSpecificMock(server); | |||
|
|||
// Mocks below this line can be overridden by test-specific mocks |
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.
I wanted to set default mocks for these requests, but override them in the phishing tests. I found that this only worked if they were declared below this line. Presumably the first handler wins with mockttp
.
cc @PeterYinusa , tagging you in case I'm missing something here, since you set this up.
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 tagging me here. I think I should probably add some comment blocks/documentation to provide clarity on the mocks.
Personally, I feel it needs to be cleaned up a little, as the use cases increased as we added additional test cases. Here's some general info on how it's intended to work at the moment.
- Global mocks: Mocks in this file are supposed to be global (across all tests). These mocks are set up
before
the extension is installed. - Local mocks: Some mocks are specific to a single test. In this case, we use do not put them in the global mocks file, but instead place them directly in the test. Another reason we may place the mock directly in the test, is so we can do assertions on the requests.
- Local pre-installation mocks: These are mocks that need to be in place before the extension is installed and are specific to a single test.
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, that all makes sense.
This case still isn't clear though. Here I want to use a global mock, but override it for a specific test. Does placing it here before the invocation of the local pre-installation mocks make sense? Should we let all global mocks be overridden in this way?
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.
Created an issue here to tidy things up #17843
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.
Presumably the first handler wins with mockttp.
I believe this is the case.
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.
Does placing it here before the invocation of the local pre-installation mocks make sense? Should we let all global mocks be overridden in this way?
This makes sense to me. Then we can actually remove the usage of a reset here and make it a test-specific mock
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.
Actually, in reference to my comment above, we would still need a way to do assertions on a request.
But your suggestion seems sound to me.
This comment was marked as resolved.
This comment was marked as resolved.
f712ac3
to
5b8597f
Compare
This comment was marked as resolved.
This comment was marked as resolved.
d7e3284
to
5a05979
Compare
Builds ready [5a05979]
Page Load Metrics (1645 ± 74 ms)
Bundle size diffs [🚨 Warning! Bundle size has increased!]
|
This comment was marked as resolved.
This comment was marked as resolved.
@Gudahtt looking at the other PR you linked, I saw this unresolved question: https://github.com/MetaMask/phishing-warning/pull/52/files#r1106413619 Was it addressed at some point? |
const mux = setupMultiplex(connectionStream); | ||
const phishingStream = mux.createStream('phishing'); | ||
phishingStream.write({ hostname, newIssueUrl }); |
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.
should newIssueUrl
be removed from the redirectToPhishingWarning
function in contentScript as well?
const { newIssueUrl } = data; |
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.
Yes, great catch
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.
Done here: 5ab6a37
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.
I have a couple of questions and can approve from a code review perspective once they are resolved.
Also, I see that this has been marked for manual QA from the QA team @PeterYinusa @chloeYue @tmashuang
Yes, just replied to that with a link to the PR where the test was restored. Though all of those tests were later replaced by Playwright tests anyway. |
5a05979
to
5ab6a37
Compare
Builds ready [5ab6a37]
Page Load Metrics (1505 ± 38 ms)
Bundle size diffs [🚨 Warning! Bundle size has increased!]
|
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.
LGTM
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.
LGTM
The PhishingController has been updated to v2. This release should dramatically reduce network traffic and double the update speed of the phishing list. This was accomplished by combining both of our phishing configurations into one list (the "stalelist"), then creating a separate list of the changes just the past few days (the "hotlist"). Now users will download a smaller list more frequently (every 30 minutes rather than every hour), whereas the full list is only updated every 4 days. The combined configuration means that we no longer know which list was responsible for each block. The phishing warning page has been updated to dynamically look this information up, to ensure users are still directed to the correct place to dispute a block. This update to the phishing warning page also includes the recent redesign.
5ab6a37
to
37cb677
Compare
Rebased to resolve a conflict in |
QA test OK, LGTM, thanks! |
Builds ready [37cb677]
Page Load Metrics (1509 ± 42 ms)
Bundle size diffs [🚨 Warning! Bundle size has increased!]
|
The PhishingController has been updated to v2. This release should dramatically reduce network traffic and double the update speed of the phishing list.
This was accomplished by combining both of our phishing configurations into one list (the "stalelist"), then creating a separate list of the changes just the past few days (the "hotlist"). Now users will download a smaller list more frequently (every 30 minutes rather than every hour), whereas the full list is only updated every 4 days.
The combined configuration means that we no longer know which list was responsible for each block. The phishing warning page has been updated to dynamically look this information up, to ensure users are still directed to the correct place to dispute a block. This update to the phishing warning page also includes the recent redesign.
Screenshots/Screencaps
The architectural changes can't be seen visually, but this PR also includes the phishing warning page redesign.
You can see those differences visually by looking at this the description for this PR: MetaMask/phishing-warning#52
Manual Testing Steps
To test the new phishing warning page design, you can go through the usual steps to test the phishing warning page (see our phishing warning e2e tests for a few example workflows).
For the architectural changes to how the phishing configuration is updated, we can prepare and install a build, then wait for a phishing config update (maybe we can coordinate with one of the
eth-phishing-detect
maintainers to merge something at the right time). You should see the update within 0-60 minutes (max 30 minute delay on our API updating, and max 30 minute delay on the client requesting the updated config from the API). You could leave the background process dev tools open to see the network request, and confirm that it is a relatively small diff.Pre-merge author checklist
Pre-merge reviewer checklist
If further QA is required (e.g. new feature, complex testing steps, large refactor), add the
Extension QA Board
label.In this case, a QA Engineer approval will be be required.