LINUX.ORG.RU

История изменений

Исправление KivApple, (текущая версия) :

При первой загрузке страницы показываешь юзеру «Проверка безопасности, пожалуйста, подождите». В это время спаунишь Web Worker, который брутит SHA256 с N ведущих нулевых бит. После успеха сабмиттишь результат на бекэнд и он ставит некий токен в куках (для простоты можно JWT). При наличии этого токена последующие запросы идут без этой проверки (можно вести учёт использования таких сессий со стороны бекэнда и если подозрительно много запросов за единицу времени инвалидировать токен, чтобы юзер снова проходил проверку).

N подбирается таким, чтобы даже на слабых устройствах «проверка» проходила за 2-3 секунды, не больше.

Но вообще надо определиться от чего защищаешься. Если от скрапинга публично доступных данных, то тут вопрос лежит не в технической, а в психологической сфере. Походи к психологу, поработай над навыками принятия ситуации. С сервером ничего делать не нужно. Ну кроме простейших вещей типа подгрузки данных с помощью JS вместо статического рендеринга (но это автоматически прощай индексация поисковиками, сайт не могут найти - сайт умер). Простых ботов, которые просто парсят HTML остановит, ботов которые запускают headless браузер и могут выполнять JS не остановит НИЧЕГО (если данные доступны без авторизации). Многократно проверено.

Если защищаешься от спама или брутфорса формы логина, то капча/proof-of-work описанный выше. Ещё опционально временный бан по IP, если слишком много неудачных попыток.

Исходная версия KivApple, :

При первой загрузке страницы показываешь юзеру «Проверка безопасности, пожалуйста, подождите». В это время спаунишь Web Worker, который брутит SHA256 с N ведущих нулевых бит. После успеха сабмиттишь результат на бекэнд и он ставит некий токен в куках (для простоты можно JWT). При наличии этого токена последующие запросы идут без этой проверки (можно вести учёт использования таких сессий со стороны бекэнда и если подозрительно много запросов за единицу времени инвалидировать токен, чтобы юзер снова проходил проверку).

N подбирается таким, чтобы даже на слабых устройствах «проверка» проходила за 2-3 секунды, не больше.

Но вообще надо определиться от чего защищаешься. Если от скрапинга публично доступных данных, то тут вопрос лежит не в технической, а в психологической сфере. Походи к психологу, поработай над навыками принятия ситуации. С сервером ничего делать не нужно. Ну кроме простейших вещей типа подгрузки данных с помощью JS вместо статического рендеринга (но это автоматически прощай индексация поисковиками, сайт не могут найти - сайт умер). Простых ботов, которые просто парсят HTML остановит, ботов которые запускают headless браузер и могут выполнять JS не остановит НИЧЕГО.

Если защищаешься от спама или брутфорса формы логина, то капча/proof-of-work описанный выше. Ещё опционально временный бан по IP, если слишком много неудачных попыток.