Files
autoreg-skills-max/skills/ai-provider-autoreg/references/oauth-door-signup-grant.md

43 lines
5.1 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# OAuth-дверь как обход капчи для signup-грантов (класс-техника)
Проверено на 2 сервисах (beatapi.io, treg.to): email-дверь регистрации может платить $0/не давать бонус, хотя регистрация E2E проходит. Причина: сервер классифицирует captcha-токен (Cloudflare Turnstile outcome / score) и тихо понижает promo-элиджибле — токен проходит siteverify, но outcome != PASS → юзер создаётся с promo_eligible=False.
## Правило
**Если email-рега даёт акки без signup-бонуса — НЕ чини капчу, проверь социальную дверь (GitHub/Google OAuth).** OAuth-signup обычно: (1) вообще без капчи, (2) создаёт юзера с promo-элиджибле по дефолту (captcha-классификация не участвует), (3) whitelist почт применяется и к OAuth — нужен GH-акк с verified почтой из whitelist-доменов.
## Диагностика до реализации
1. Регистрация проходит, но баланс $0 → ищи в реверс-коде/бандле: `promo_eligible`, `signup_bonus`, `claim.*promo`, `turnstile.*outcome`, `score`.
2. Признак капча-классификации: грант-логика gated на `outcome == PASS` / score-порог, а не на факт верификации.
3. Признак dead-end email-двери: несколько свежих регов подряд $0 при живом сервисе и рабочем OTP.
4. Ищи OAuth-двери: `/auth/github`, `/auth/google`, client_id в бандле/302 Location; даже если `native github_oauth=false` в конфиге — custom_oauth_providers может быть жив (beatapi).
## Антифрод grant-claim'ов (treg-паттерн, вероятно типовой)
- Claim уникален ПО INBOX, не по юзеру: +tag снимается у всех доменов, точки у gmail/googlemail → gmail-алиас/дот-фермы для грантов мертвы навсегда; отдельные ящики (t-online, outlook) — каждый новый inbox.
- Съеденный claim не чинится: повторное создание орга/ключа на том же юзере = снова $0. Не жечь запросы на retry — сразу следующий акк.
- Хитрейт <100% при свежих почтах = часть inbox уже засвечена или есть скрытый per-IP/рейт-лимит — мерять на выборке 10+, не на 2 акках.
## Механика GH-OAuth реги (http-only, без браузера на стороне сервиса)
1. GET двери (302) → выцепить client_id, state, state-cookie.
2. Логин GH-акка (password+TOTP) существующей GHSession-библиотекой (regfarm/github_oauth/gh_http.py).
3. GET authorize ПОЛНЫМ URL (redirect_uri обязателен; уже-авторизованные акки отдают meta-refresh страницу с code в body — regex на `code=`).
4. GET callback?code&state с state-cookie → сессионная cookie сервиса.
5. Создание орга/ключа → токен НОВОГО орга приходит В ОТВЕТЕ создания; старые токены per-org/per-team → 403 «belongs to another team». Сохранять полный JSON (обрезанный print теряет токен безвозвратно).
6. Баланс-чек сразу: поле может быть `balance_micro` (не `balance`), заголовок аутентификации — кастомный (`X-Treg-Token` + protocol), не Authorization Bearer.
## Волна/масштабирование
- Пул-файлы переключать env-переменными (GH_POOL/GH_STATE), свой state на каждый пул — idx позиционный, общий state на два пула = пропуск/дубль акков.
- Дедуп пула перед волной: минус login'ы банка минус login'ы других пулов.
- Волновой луп: батчи N, пауза между волнами, стоп = state idx >= len(pool) (проверка state-файлом, не grep лога).
- Flagged/сuspended GH-акки: authorize редиректит на /dashboard БЕЗ code → skip, не ретраить.
- Темп ~15-25с/акк обычно без 429; при 429 — пэйсинг 60+ и повторный заход через 1-2ч (лимит на OAuth-приложение/регион).
## Конкретные реализации
- treg.to: skill treg-to-farm, секция «ГРАНТ через GITHUB OAUTH» (gh_grant_test.py, build_big_pool.py, gh_big_wave.sh).
- beatapi.io: tmp/beat_autoreg/beat_gh_reg.py, custom_oauth_providers client_id; whitelist gmail/163/qq/icloud/yahoo/foxmail — hotmail/outlook-когорта GH-пула фейлит.