-
Notifications
You must be signed in to change notification settings - Fork 2k
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
Initial work on a new Security Checkup feature. #43101
Conversation
Work items include: * Set up the `security/security-checkup` feature flag and limit the feature to dev environments * Create `SecurityCheckupComponent` with basic styling and wire it into the security nav * Wire in the following links and basic assessments: - Account email - 2FA configuration - Recovery email - Recovery phone/SMS number - Connected apps
Here is how your PR affects size of JS and CSS bundles shipped to the user's browser: Sections (~1366 bytes added 📈 [gzipped])
Sections contain code specific for a given set of routes. Is downloaded and parsed only when a particular route is navigated to. Legend What is parsed and gzip size?Parsed Size: Uncompressed size of the JS and CSS files. This much code needs to be parsed and stored in memory. Generated by performance advisor bot at iscalypsofastyet.com. |
<SecurityCheckupNavigationItem | ||
path={ '/me/security/account-recovery' } | ||
materialIcon={ icon } | ||
text={ translate( 'Recovery SMS Number' ) } |
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.
ℹ️ String reuse speeds up translation and improves consistency. The following string might make a good alternative and has already been translated 42 times:
translate( 'Recovery SMS number' )
ES Score: 15
See 1 additional suggestions in the PR translation status page
Nice, the screenshot and options look good! Just curious about the "Security checkup" dropdown and where this screen fits in to the security section of /me? |
Thanks for taking a look, @fditrapani! The dropdown seems to be a "feature" of the This is definitely on my to-fix list! |
OK, so the dropdown/width solution is going to be messy... each component in |
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.
Tested - already looking really promising! Verified that without the feature flag there does not appear to be any regressions as well 👍
renderVerticalNav() { | ||
return ( | ||
<VerticalNav> | ||
{ this.renderAccountEmail() } |
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.
It might be already on your radar, but I'd suggest splitting each of these rows/render*
calls into separate components. On their own, they are not that complicated, but even this "skeleton" version of the component is already over 400 lines long and I imagine it will get longer as more logic is added.
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.
That was definitely starting to become more apparent as I added new rows -- the code and the dependencies started to become unwieldy. So I'll shift the new rows to components tomorrow and then loop back to the items I've already implemented.
I actually think it's pretty good as-is. You could simplify the first item by omitting "set to" so it just reads "Your account email is [email]" but that's fairly nitpicky. For the recovery options (email, SMS), I'm wondering if users will understand what this is. We could link them to relevant support docs, which might actually not be a bad idea across the board.
Agree, this looks like a nice starting point though would be nice to use colors/icons so that users can grok at a glance which items need attention.
Not sure we want to go down the path of indicating good/strong PWs here, especially since we already have something that checks that upon account creation. Perhaps an indicator of when the last time was that the PW was reset, eg "Your password was last changed on [date]". We could then show [date] in yellow if it's been more than (let's say) a year with a tool tip suggestion to consider updating it. |
This Pull Request is now available for translation here: https://translate.wordpress.com/deliverables/3792313 Thank you @daledupreez for including a screenshot in the description! This is really helpful for our translators. |
Good call. It's a tricky problem to work around but here's one potential solution: We can make this new screen the landing page for Security where it can double as a status screen and navigation which will allow us to trim down the section navigation. |
Thanks for working on this, @fditrapani! I think it would be cleaner if we shift the conversation to #43144 so we can clearly focus on this specific problem. |
Translation for this Pull Request has now been finished. |
Changes proposed in this Pull Request
This PR sets the groundwork for a new Security Checkup feature (described here), which is currently set up behind the
security/security-checkup
feature flag, which is limited to dev environments for now.The goal is to show a quick overview of a user's security and account recovery settings. For now, this initial PR does not represent a wrapped product, but a basic skeleton to support further iteration.
At present, this PR includes the following items:
SecurityCheckupComponent
with basic styling and wire it into the security navOpen issues
I'll address these in subsequent iterations/PRs.
userSettings
and the 2FA logic, including expanding the assessment to include backup codesSide note: A huge 🎩 to @fditrapani! I cribbed his designs for the new domain settings UI for the basic layout, as the core UX in the two screens is very similar.
Testing instructions
Relates to #26874, though it doesn't directly address all of the items in the issue yet.