vlad/autoreg-skills-max
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
main
autoreg-skills-max/skills/ai-provider-autoreg/references/oauth-door-signup-grant.md

5.1 KiB
Raw Permalink Blame History

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-пула фейлит.