Проверяйте визит, а не только адрес.

Защита регистрации добавляет к проверке адреса сигналы о самом визите. Она нужна там, где адрес выглядит нормально, но запрос не совпадает с визитом, из которого он должен был прийти: форму отправили, не открывая страницу, токен взяли из прежней сессии или форму отправили через мгновение после загрузки страницы.

Сигналы не устанавливают личность человека и не доказывают злоупотребление. Каждая находка — это свидетельство для ваших собственных правил, а рекомендуемое действие никогда не строже подтверждения почты.

Добавьте токен на страницу регистрации

Откройте в аккаунте раздел Защита регистрации и создайте ключ страницы для origin вашей страницы регистрации, например https://example.com. Ключ страницы не секрет: его видит любой, кто открыл страницу, и работает он только с тех origin, которые указаны у ключа.

Сниппет из аккаунта добавляет скрытое поле и небольшой скрипт. Когда форма показана, скрипт запрашивает у узла выдачи токен визита и записывает его в поле, а форма отправляет это поле вместе с остальными. Если скрипт заблокирован или узел не ответил, поле остается пустым, и проверка попросит подтвердить почту, а не отклонит регистрацию. В документации описаны скрипт, его версия и строки Content-Security-Policy для вашей страницы.

Передайте токен со своего сервера

При регистрации ваш сервер передает токен вместе с адресом и данными соединения посетителя в POST /v1/signup-checks. Для этого нужен тот же API-ключ, что и для проверки email, и он остается на сервере.

curl -sS https://api.emvero.tech/v1/signup-checks \
  -H "Authorization: Bearer emv_your_credential" \
  -H "Content-Type: application/json" \
  -d '{"email":"ada@example.com","token":"<значение поля fp_token>","ip":"203.0.113.7","user_agent":"Mozilla/5.0 (Windows NT 10.0; Win64; x64) ..."}'

Client Hints, если ваш сервер их получает, передаются в объекте client_hints. В ответе есть одно action для регистрации, коды signal_codes, которые его подняли, полный результат проверки email и сигналы. Ниже приведены отдельные поля примерного ответа. Это иллюстрация, а не результат реальной проверки:

{
  "id": "0b8e6f2a-4d1c-4f7e-9a3b-2c5d6e7f8a90",
  "action": "allow_with_email_confirmation",
  "signal_codes": ["fp_fast_submission"],
  "email": { "status": "deliverable", "action": "allow", "reason_codes": [] },
  "signals": {
    "status": "evaluated",
    "findings": [
      { "code": "fp_fast_submission", "class": "binding", "default_raises": true },
      { "code": "fp_network_vpn", "class": "identity", "default_raises": false }
    ]
  }
}

Адрес здесь доставляемый, и одна проверка email пропустила бы его. Но форму отправили почти сразу после того, как страница получила токен, а такая находка поднимает решение. Поэтому action равно allow_with_email_confirmation, а signal_codes называет причину. Посетитель к тому же был в VPN: эта находка показана в ответе, но сама по себе решение не поднимает.

Если адрес вы уже проверяете отдельно, POST /v1/signup-signals принимает тот же запрос без email и отвечает так, как если бы проверка email вернула allow.

Как сигналы меняют решение

Сигналы могут поднять allow до allow_with_email_confirmation. Они никогда не поднимают решение до reject и не смягчают решение проверки email.

Если проверка email еще в pending, сигналы уже окончательны, а action равно allow_with_email_confirmation. Запросите GET /v1/signup-checks/{id} через email.retry_after_ms: опрос бесплатный, и действие пересчитывается по завершенной проверке email и сохраненным кодам сигналов.

На что смотрят сигналы

• Токен. Решение поднимается, если токена нет, он истек, изменен, выдан для страниц другого аккаунта или предъявлен второй раз.
• Визит и запрос. Решение поднимается, если IP-адрес или браузер при отправке отличаются от тех, кому выдан токен, или если форму отправили почти сразу после первого токена.
• Сеть и заявления браузера. VPN, Tor, публичные прокси, частные ретрансляторы, хостинговые сети, а также часовой пояс или платформа, которые не сходятся с соединением, попадают в ответ для ваших собственных правил. Сами по себе они решение не поднимают.

У каждой находки есть default_raises: это поле говорит, поднимает ли она решение. Находки, которые решение не поднимают, тоже остаются в результате, и ваше приложение может применить к ним свои правила. Полный список кодов приведен в документации.

Сервис сигналов также собирает список адресов и сетей, которые недавно работали на ваших страницах как посредники. GET /v1/relay-list отдает его бесплатно, с лимитом запросов в минуту. По нему можно проверить запросы, которые не открывали вашу страницу, например обращение мобильного приложения к вашему API.

Сколько стоит проверка

Совмещенная проверка дополнительно списывает проверку email так же, как POST /v1/verifications. Выдача токенов, опрос незавершенной проверки и список посредников бесплатны. Все списания идут с общего баланса аккаунта. Если баланса не хватает, проверка отвечает 402 и не начинает работу.

Что происходит с данными посетителей

Ваш сервер передает токен, IP-адрес посетителя, User-Agent и Client Hints. Emvero отправляет их в сервис сигналов для оценки и не хранит ни в журналах, ни в базе; в сохраненном результате нет ни IP-адреса, ни его части. Сервис сигналов получает код клиента вашего аккаунта, но никогда не получает email-адрес или идентификатор аккаунта. Результаты хранятся 30 дней, как и результаты проверки email.

На время пилота каждый участник подписывает отдельное письменное соглашение, которое регулирует обработку данных посетителей сервисом сигналов.

Управление в аккаунте

Когда защита включена, в аккаунте видны ее состояние, ключи страниц с их origin, сниппет для каждого ключа и число соединений, записанных с вашими ключами, по дням. Ключ можно отозвать в любой момент. Чтобы выключить защиту регистрации и удалить ее данные, напишите нам.