feat(leads): sign in to seed directories that gate their listings

[ralyodio]

Follow-up to #128, which could tell a login wall apart from an empty directory. This is the part that gets past one.

Generic, not per-site

A per-directory login script is the thing worth avoiding — every gated directory would need one, and each would break on its own schedule. A login form is standardised enough to drive blind: one password field, one identifier field near it, one submit.

The password field is the anchor. A page without one is refused rather than guessed at, so this can't wander off filling arbitrary forms.

Submitting prefers clicking a submit button (some forms bind handlers to it) and falls back to pressing Enter in the password field (for forms whose "button" is a styled div).

Verified live against a real login form:

form present   : true
submitLoginForm: { ok: true }
url after      : https://quotes.toscrape.com/   (redirected off the form)
logged in?     : true                            (page shows Logout)
no-form case   : { ok: false, error: 'no password field was found on the login page' }

Session handling

Sign-in happens on the context that already hit the wall — the redirect has put the form in front of us, and the session cookies have to survive into the retry. The original URL is then requested again and re-checked: signing in successfully and still being asked to log in means the account can't see that page, which is a different problem and reports as one.

waiting_for_auth

A campaign parked on a gated directory isn't failing — it's waiting on something only the user can supply. Gated hosts are recorded on the campaign (auth_required_hosts), surfaced in the tick summary as waiting_for_auth, and shown in a panel where each host carries the form that unblocks it. Saving a credential clears the wait.

Only counts as waiting when there's nothing to try: a stored credential that failed is an error, not a wait.

Credential storage

Per host, per organization — a user has one account on a directory, not one per search they paste in. Passwords exist in the database only as AES-256-GCM ciphertext (lib/sp/vault.ts), key in the app environment.

Not verified at save time, deliberately. That would mean driving a browser through someone else's login form inside a server action, where a briefly-slow directory looks identical to a bad password. The next tick tries them and records the outcome, so the panel shows whether the login actually worked.

Honest failure modes

A site that answers with a verification code, a second factor, or a challenge can't be signed into from a server. That's detected and reported as what it is, rather than as a wrong password.

Migration

20260728010000_outreach_seed_credentials.sql — new table plus auth_required_hosts on campaigns. Already applied to prod ahead of this deploy.

Checks

• tsc --noEmit clean
• 699/699 tests pass
• production build compiles
• login automation exercised against a live form, including the negative case

🤖 Generated with Claude Code

[github-actions]

vu1nz Security Review

0 finding(s) in PR #?

No security issues found.