Site Settings: Add Jetpack Firewall Toggle to Security Settings Screen

[nateweller]

Related to https://github.com/Automattic/jetpack-scan-team/issues/1228

Depends on https://github.com/Automattic/jetpack-scan-team/issues/1321

Proposed Changes

• Adds a "Web Application Firewall (WAF)" setting card to /settings/security/[site].
• If the user does not have access to automatic rules, an upgrade prompt is displayed.
• Merges the Brute Force Protection and IP Allow List settings into the new Firewall card.

Why are these changes being made?

• See peb6dq-2v0-p2

Testing Instructions

• Check out this PR in your local Jetpack repo: WAF: Options Improvements jetpack#38580
• Boot up your local monorepo site with jetpack docker up -d and jetpack docker jt-up
• Visit your site's wp-admin and ensure Jetpack is connected
• Test this PR using the Calypso live link below, and your local test site running through Jurassic Tube.

Pre-merge Checklist

• Has the general commit checklist been followed? (PCYsg-hS-p2)
• Have you written new tests for your changes?
• Have you tested the feature in Simple (P9HQHe-k8-p2), Atomic (P9HQHe-jW-p2), and self-hosted Jetpack sites (PCYsg-g6b-p2)?
• Have you checked for TypeScript, React or other console errors?
• Have you used memoizing on expensive computations? More info in Memoizing with create-selector and Using memoizing selectors and Our Approach to Data
• Have we added the "[Status] String Freeze" label as soon as any new strings were ready for translation (p4TIVU-5Jq-p2)?
• For changes affecting Jetpack: Have we added the "[Status] Needs Privacy Updates" label if this pull request changes what data or activity we track or use (p4TIVU-aUh-p2)?

Screenshots

[github-actions]

Calypso Live (direct link)

https://calypso.live?image=registry.a8c.com/calypso/app:build-115157

Jetpack Cloud live (direct link)

https://calypso.live?image=registry.a8c.com/calypso/app:build-115157&env=jetpack

Automattic for Agencies live (direct link)

https://calypso.live?image=registry.a8c.com/calypso/app:build-115157&env=a8c-for-agencies

[matticbot]

Here is how your PR affects size of JS and CSS bundles shipped to the user's browser:

Sections (~1738 bytes added 📈 [gzipped])

name                             parsed_size           gzip_size
settings-security                    +6943 B  (+1.5%)    +1543 B  (+1.1%)
write-flow                             +12 B  (+0.0%)      +16 B  (+0.0%)
videopress-flow                        +12 B  (+0.0%)      +16 B  (+0.0%)
themes                                 +12 B  (+0.0%)      +12 B  (+0.0%)
theme                                  +12 B  (+0.0%)      +20 B  (+0.0%)
staging-site                           +12 B  (+0.0%)      +12 B  (+0.0%)
settings-podcast                       +12 B  (+0.0%)      +21 B  (+0.0%)
settings-performance                   +12 B  (+0.0%)      +15 B  (+0.0%)
settings                               +12 B  (+0.0%)      +19 B  (+0.0%)
posts-custom                           +12 B  (+0.0%)      +16 B  (+0.0%)
posts                                  +12 B  (+0.0%)      +16 B  (+0.0%)
plugins                                +12 B  (+0.0%)      +12 B  (+0.0%)
media                                  +12 B  (+0.0%)      +16 B  (+0.0%)
marketing                              +12 B  (+0.0%)      +19 B  (+0.0%)
link-in-bio-tld-flow                   +12 B  (+0.0%)      +16 B  (+0.0%)
jetpack-cloud-plugin-management        +12 B  (+0.0%)      +12 B  (+0.0%)
hosting                                +12 B  (+0.0%)      +12 B  (+0.0%)
earn                                   +12 B  (+0.0%)      +21 B  (+0.0%)
domains                                +12 B  (+0.0%)      +21 B  (+0.0%)
build-flow                             +12 B  (+0.0%)      +16 B  (+0.0%)
activity                               +12 B  (+0.0%)      +15 B  (+0.0%)

Sections contain code specific for a given set of routes. Is downloaded and parsed only when a particular route is navigated to.

Async-loaded Components (~133 bytes added 📈 [gzipped])

name                                                     parsed_size           gzip_size
async-load-design-blocks                                       +12 B  (+0.0%)      +16 B  (+0.0%)
async-load-calypso-reader-sidebar                              +12 B  (+0.0%)      +17 B  (+0.0%)
async-load-calypso-post-editor-editor-media-modal              +12 B  (+0.0%)      +15 B  (+0.0%)
async-load-calypso-my-sites-stats-summary                      +12 B  (+0.0%)      +18 B  (+0.1%)
async-load-calypso-my-sites-current-site-notice                +12 B  (+0.0%)      +13 B  (+0.1%)
async-load-calypso-components-web-preview-component            +12 B  (+0.0%)      +16 B  (+0.0%)
async-load-calypso-blocks-jitm-templates-sidebar-banner        +12 B  (+0.0%)      +19 B  (+0.1%)
async-load-calypso-blocks-jitm-templates-notice                +12 B  (+0.0%)      +16 B  (+0.1%)
async-load-calypso-blocks-jitm-templates-default               +12 B  (+0.0%)      +19 B  (+0.1%)

React components that are loaded lazily, when a certain part of UI is displayed for the first time.

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.
Gzip Size: Compressed size of the JS and CSS files. This much data needs to be downloaded over network.

Generated by performance advisor bot at iscalypsofastyet.com.

[dkmyta]

Looks and works great, with the exception the Akismet UI glitch hijacking the save, returning an error notice and not immediately reflecting the new toggle state as we discussed.

Settings updates are working and are reflected in both the Jetpack and/or Protect UIs appropriately and vice-versa. Upgrading and downgrading performs as expected and the UIs are updated accordingly.

One thing I did notice as a potential discussion point, when viewing these settings for an unsupported site, the toggles are just disabled rather than hidden as they are in the other UIs. I realize this is a difficult scenario because the BFP and Allow list settings are baked into the WAF card, but I think it may raise the question "why can I not enable these?". If hiding them is not a valid solution, perhaps we should add a notice of some sort for clarification? Thoughts?

[nateweller]

One thing I did notice as a potential discussion point, when viewing these settings for an unsupported site, the toggles are just disabled rather than hidden as they are in the other UIs. I realize this is a difficult scenario because the BFP and Allow list settings are baked into the WAF card, but I think it may raise the question "why can I not enable these?". If hiding them is not a valid solution, perhaps we should add a notice of some sort for clarification? Thoughts?

I'm not sure exactly where this is happening yet, each toggle should be conditionally rendered based on the value of wafModuleSupported() method in firewall.jsx:

! this.props.isAtomic && ! this.props.isVip

When a toggle is rendered but disabled, the logic is more complex:

! this.props.isAtomic && ! this.props.isVip || isRequestingSettings || isSavingSettings || moduleDetailsNotLoaded || ( siteInDevMode && moduleUnavailableInDevMode )

Do you know what your state would have looked like roughly, when the toggles are disabled but still being rendered on the page?

Toggles should be disabled briefly while loading, and the automatic rules toggle should be disabled when the user has no active plan but older automatic rules available. Otherwise if something isn't available, it should be hidden - but that may not be the case if this can be reproduced.

[dkmyta]

Do you know what your state would have looked like roughly, when the toggles are disabled but still being rendered on the page?

Using a Pressable site, the toggles display as follows for the Security Settings page:

I would've expected a Pressable site to fall within the this.props.isAtomic category, but for some reason is not currently recognized by that check.

[dkmyta]

Works great if Akismet is activated, but that is a separate/existing issue that will hopefully be resolved external to this.

Every scenario I could think of testing is now accounted for with one minor exception to provide for perfect parity. When in an unsupported environment we now only display the BFP and Allow list toggles, in Jetpack/Protect we disable the Allow list if BFP is disabled as it has no usage outside of that scenario.

In Calypso we still allow it to be toggled and entries added.

If we pursue this change, I think we may need to also ensure this is the case in the backward compatible version if that is at all handled uniquely.

[nateweller]

@dkmyta What do you think about leaving the IP allow list available when the firewall/login protection features are turned off? My thinking being that you may want to allow list your own address prior to turning back on one of the features.

Perhaps we can sync up on how to present different WAF settings (i.e. show lists vs disable them when toggled off, disable or hide allow list when other features off, etc) with design during our meetup?

My proposal then being, let's merge this and follow up more broadly 😅

[a8ci18n]

This Pull Request is now available for translation here: https://translate.wordpress.com/deliverables/16462881

Some locales (Hebrew, Japanese) have been temporarily machine-translated due to translator availability. All other translations are usually ready within a few days. Untranslated and machine-translated strings will be sent for translation next Monday and are expected to be completed by the following Friday.

Thank you @nateweller for including a screenshot in the description! This is really helpful for our translators.

[a8ci18n]

Translation for this Pull Request has now been finished.