Caputchin
Страничный шлюз на прокси

Поставь шлюз перед целым сайтом на своём обратном прокси

Открыть как Markdown

Обычный способ пользоваться Caputchin состоит в том, чтобы встроить виджет на страницу и проверить токен на своём бэкенде. Для этого нужно место под виджет и бэкенд для проверки токена. Страничному шлюзу на прокси не нужно ни того, ни другого. Он ставит полностраничную проверку перед целым сайтом или маршрутом на твоём обратном прокси: посетитель проходит одну проверку, зарабатывает недолгий пропуск и гуляет по сайту, пока пропуск не истечёт. Проверка это короткая игра или подтверждение одним касанием, что выберешь. Защищаемое приложение не трогают вовсе.

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

Для кого он

Тянись к шлюзу, когда встроенный виджет не подходит:

  • У приложения нет места под виджет. Запечатанный портал входа (как Authelia), аплайанс поставщика, или любой UI, который ты не можешь править.
  • Ты хочешь закрыть шлюзом целую поверхность, а не одну форму. "Докажи, что ты человек, прежде чем дойти до этого сайта" вместо проверки на одной отправке.
  • У тебя нет бэкенда для проверки токена. Обеспечивает правило прокси; нет вызова /siteverify, который надо писать.

Для обычной страницы или формы, которую ты контролируешь, лучше встрой виджет, он легче и не перенаправляет посетителя. Если у тебя есть форма, но нет бэкенда, размещённая проверка подходит лучше.

Как это работает

Одно решение покупает много запросов. Посетитель проходит проверку один раз; после этого cookie первой стороны пропускает его запросы, пока не истечёт.

Прокси делает маленький вызов авторизатора Caputchin на каждый запрос. Когда запрос не несёт валидного пропуска, Caputchin отвечает 401 и прокси перенаправляет посетителя на размещённое испытание. Когда пропуск на месте и валиден, Caputchin отвечает 204 и прокси пропускает запрос к твоему приложению.

Пропуск живёт в cookie первой стороны, по умолчанию с именем cpt_gate и переименуемой на каждом ключе сайта, которую на твоём собственном домене ставит маленький callback, размещённый тобой (по умолчанию на /__cpt/callback, его тоже можно перенести). Это подписанный недолгий токен, не привязанный к устройству, так что его безопасность целиком идёт от атрибутов cookie (HttpOnly, Secure, SameSite=Lax) и короткого TTL, который ты выбираешь. Поскольку он ставит cookie твоим посетителям, раскрой это в своей политике cookie. Руководство по настройке проходит через callback и необходимые атрибуты.

Что намеренно оставлено за бортом

  • Нет саморазмещаемого шлюза. Caputchin размещает испытание и проверяет пропуск; ты не запускаешь проверяльщик. Твой прокси только пересылает cookie и следует редиректам.
  • Проверка на каждый запрос, а не локальная валидация токена. Прокси спрашивает Caputchin на каждом запросе. Режим отказа, который ты выбираешь (открытый или закрытый), решает, что будет, если Caputchin ненадолго недостижим.
  • Пропуск на ключ сайта, с областью cookie. Пропуск пропускает один источник, не целый аккаунт и не несколько доменов, потому что это обычная cookie первой стороны.
  • Никаких своих формулировок. Ты выбираешь язык и тему страницы проверки, а не её текст.
  • Не сессия и не вход. Шлюз доказывает, что человек дошёл до сайта; твоё приложение по-прежнему занимается аутентификацией и своими лимитами частоты. Двое складываются.

Что видит посетитель

Страница проверки говорит на языке самого посетителя и следует его светлому или тёмному предпочтению, и несёт тот же бренд, что и виджет на этом ключе сайта, потому что и то и другое она берёт из того же ключа сайта, который ты уже настроил. Вместо этого можно закрепить язык или тему и выбрать между игрой и галочкой в одно касание, на странице Шлюз на прокси ключа сайта. Смотри Настрой испытание под себя.

См. также

На этой странице