What cannot be automated
Second factors, magic links and SSO — where form-login stops, what to use instead, and one gap that is not built yet.
Some sign-ins cannot be performed by a machine, and a few should not be even where they can. This page is the boundary, said plainly, so that nobody spends an afternoon configuring their way across it.
Where form-login stops
| Shape | Covered | Notes |
|---|---|---|
| One-step form | yes | |
| Two-step — address, then password | yes | Continue is the submit control unless configured otherwise. |
| Gated form — region picker, "sign in with email" | yes | ADAPTER_LOGIN_PRE_STEP. |
| Single-page application, no navigation | yes | |
| Interstitial after the password | no | "Stay signed in?", "Remember this device". |
| Second factor — code, app, push | no | Deliberately. See below. |
| Magic link | no | There is no password to type. |
| SSO redirect to an identity provider | partly | It is another form; it works if that form has no second factor. |
The failure to recognise
An interstitial or a second factor produces a false success, which is the bad kind. Sign-in is judged complete when the password field goes away — and a code prompt satisfies that perfectly. The adapter reports success, the run starts, and step one fails against a screen nobody expected.
It is at least visible: the run's failure frame shows the prompt. But do not read "signed in" from a green adapter on an account with MFA enabled.
Why a second factor is refused rather than solved
A tool that can complete your second factor has removed your second factor. The credential it would need — a shared TOTP seed, a mailbox, an approval device — is worth more than the password it protects, and it would sit on whatever machine runs your content pipeline.
Use a test identity without MFA for the environments you replay, or use a session.
What to use instead
A token. If your application will issue one to your own auth endpoint, the token adapter asks
for it and attaches it. Nothing is typed, nothing is on screen, and a redesign of the sign-in page
cannot break it. api-key is the same idea for a key issued once.
A session. One person signs in by hand — MFA, magic link, SSO, whatever it takes — and the walk is recorded from there. This is the general answer for recording, because it does not care how the login worked: see keeping a session.
Authoring reuses a session by default; a run asks. record and survey restore the saved session and keep it, and
discover and scenario always have. script and run take --session, because a script carries its own sign-in
and a run is an artefact other people trust — one that passed only because a session was lying about would fail on a
machine that has never signed in. So a hand sign-in makes a product behind SSO authorable, and an unattended replay
still wants an adapter or a token.
A mailbox, for magic links. Technically possible — IMAP, a test-mail service, a dev-mode endpoint — and worth resisting as a default: it makes Fixtureframe hold a mailbox credential and turns every run into a race with an email. A workspace adapter can do it for one customer who has decided they want that.
Writing your own
When none of this fits, an adapter of your own is a plain file in your workspace — how to write one covers the scaffold, the hooks, and how to register it.
One rule worth repeating
Whatever route you choose, no password should ever be typed while recording. ff record
starts paused when it cannot sign in for you, and a script uses pause() and resume() around the
part that must not be filmed. The recorder writes down what is typed — including into a password
field — and a mask drawn over it in the editor is not baked into an exported still today.