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

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

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

Для кого он

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

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

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

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

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

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

Cookie пропуска

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

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

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

См. также

• Настрой прокси-барьер: включи его и подключи свой прокси от края до края.
• Рецепты обратного прокси: nginx, Traefik, Caddy, и разобранный пример Authelia.
• Статистика прокси-барьера: читай отношение прямого пропуска к испытаниям.
• Размещённая проверка: вариант без бэкенда, когда у тебя всё же есть форма, чтобы направить её на нас.