Auth Form + Rate Limits
The form is five minutes, and a good agent normalizes the email and hides which field was wrong for free. What it can't guess is which address variants are the SAME account, and that the lockout has to be keyed on that account — not the raw string an attacker can rewrite.
Build a single sign-in page for a web app. The page renders an email field and a password field, each with room for an inline validation message, a submit button that signs the user in, a region for a general authentication error, and a success state the page reaches once the user is signed in. The registered account is the email user@acme.com with the password correct-horse; any other sign-in is a failure.
The form must validate input before it submits, surface a clear message when a sign-in fails, and reach an unmistakable signed-in state for the registered account. Keep the experience usable for a real person signing in — including the ways people actually type and address an account, and the variations of the same email a real user will enter — while staying unfriendly to someone hammering the form with guesses.
Treat the credential above as one written form of the account, not the only one. Your spec must define WHICH submitted emails count as the same account and which do not, precisely enough that an agent matches every legitimate way to address it and rejects the rest. It must also define the form's defense against repeated failed attempts precisely enough that the defense actually holds — including what the defense counts and keys against, so it cannot be sidestepped by an attacker who varies how they write the email between attempts.
Entering user@acme.com and correct-horse signs in and reveals the welcome state. Entering any other email or password leaves the user on the form with an authentication message.
- Email and password fields.
- Inline validation for the fields.
- A submit button with a clear in-flight / submit state.
- Show an authentication error on a failed sign-in.
- Reach a signed-in success state on the correct credentials.
The functional tests are shown, and the model usually clears them on its own. The hidden tests are the twists this kind of system is full of. They are not listed. Your spec only passes them if it already knows where this domain breaks.
102 chars
Your build previews here
Write a spec, then run the tests to build and preview the app.