Protect the form

A disabled submit button stops repeated clicks in one browser page. Someone can still send requests directly to the site. Before enabling public email, we'll set a limit on repeated submissions and check that it takes effect.

Keep Production email credentials unset. We'll test the rule against the existing production domain with incomplete form data, so this check won't send an inquiry.

Outcome

Verify that a Vercel Firewall rule blocks repeated workshop submissions while normal page visits still work.

Hands-on exercise 4.6

Match the form requests

A browser uses a GET request to open a page. Submitting our form sends a POST request to its workshop page. The Firewall can count matching requests and block them after a limit.

Open the existing workshop project's Firewall. Review pricing, then create this rule:

A 429 response tells the caller it has made too many requests. Choose the blocking action, rather than an action that only records traffic. Publish the rule using Vercel's rate-limit setup.

Check the environment coverage in the dashboard. Verify this rule against Production before adding its email credentials. Keep Preview protected while testing email there.

Send an incomplete request

In your terminal, replace the placeholder with the production domain followed by /workshops/a-garden-in-a-pot:

curl --silent --output /dev/null --write-out '%{http_code}\n' --request POST --data 'email=invalid' 'PASTE_PRODUCTION_WORKSHOP_URL_HERE'

curl sends the HTTP request. This command prints the response status and discards the response body. The submitted data is deliberately incomplete, so it can't pass the inquiry validator.

Use Up Arrow and Enter to run it six times within 60 seconds. Look for a 429 response after reaching the limit, then find the matching event under the Firewall rule. Earlier requests may return 404 because the detail page hasn't been released yet. We are checking whether the Firewall blocks the repeated POST requests.

Check the limits of the rule

An IP address can be shared by several people, so this rule may also limit visitors on the same network. It won't stop requests spread across many addresses or cap total email spend. Set service usage alerts for this demo.

Keep the rule enabled while doing later email checks. If you reach the limit, wait for the window to expire before testing another inquiry.

Try It

Record the rule's environment coverage and the observed 429 event. Open the production homepage and use its catalog link; normal GET navigation should still work.

When the request window has expired, make one more incomplete POST request. Check that the same rate-limit rule no longer blocks it. Save these observations for the release note in 4.7.

Six requests never produce a 429

Check the method and path conditions, including the trailing slash in /workshops/, and confirm the rule covers the domain's environment. Requests may also have crossed two fixed windows. Wait for a fresh window and repeat the small test while watching the rule's events.

The rule can't be configured or verified

Check the available Firewall features and your account's permissions. Leave Production email credentials unset until this requirement is complete. You can continue reviewing a protected preview, but the public email release must wait for verified protection.

Commit

This is a project-setting checkpoint, so there is no source commit. Record the rule and its verified behavior in your course notes. Leave the application branch and Production email settings as they are.

Done-When

• The published rule matches POST requests under /workshops/ and covers Production.
• Repeated requests produce a 429 and a matching Firewall event.
• Normal page navigation works, and the rate-limit block clears after its window.
• Service usage alerts are set and the verification note is saved for release.

Solution

The rule limits each IP address to five matching requests in a fixed 60-second window. Verification requires both the observed 429 and the corresponding Firewall event; saving the configuration alone doesn't show that it matches the form's requests.

Keep Production email disabled until the preview review in the next lesson passes. The test result belongs in that release review.