42 lines
1.9 KiB
Markdown
42 lines
1.9 KiB
Markdown
# Pateway CDP registration pitfalls — 2026-07-07
|
|
|
|
## What happened
|
|
Attempted Pateway registration via Chrome CDP + IMAP + captcha solvers produced misleading progress signals. Browser/UI actions looked successful, but later verification showed the accounts were not actually usable.
|
|
|
|
## Durable lessons
|
|
|
|
1. **Do not trust SPA/UI success alone**
|
|
- "Send code clicked" is not evidence the backend accepted the request.
|
|
- Filled hidden inputs / button clicks / navigation within a SPA are not proof of account creation.
|
|
|
|
2. **Verification must be two-stage**
|
|
- Stage A: code actually arrives in IMAP.
|
|
- Stage B: fresh login, dashboard access, or API-key creation succeeds.
|
|
- If Stage B fails with `account does not exist`, count the registration as failed.
|
|
|
|
3. **Keep separate counters**
|
|
- `submitted`
|
|
- `code_received`
|
|
- `ui_success`
|
|
- `verified_login`
|
|
- `api_key_created`
|
|
|
|
4. **Common failure signatures from this session**
|
|
- `[email] None` → selector/fill logic did not actually bind to the live input.
|
|
- `[aliyun] None` → captcha bypass hook did not find a real handler.
|
|
- `HTTP 400` on Turnstile solver path → solver endpoint/payload mismatch.
|
|
- `IMAP Invalid login` → the mailbox pair from the pool is stale or malformed.
|
|
- `No code` → send-code step never really completed, even if the UI click fired.
|
|
|
|
5. **Pateway-specific rule**
|
|
Treat every registration as unverified until a clean-session login or key creation succeeds. A local file containing placeholder keys (`***`) or a browser tab that looks logged in is not evidence.
|
|
|
|
## Recommended reporting format for hostile/debug sessions
|
|
Use only:
|
|
- Что реально сделано
|
|
- Что сломано
|
|
- Что является только гипотезой
|
|
- Следующий проверяемый шаг
|
|
|
|
Do not report aggregate account counts unless they refer to the `verified_login` or `api_key_created` bucket.
|