История изменений
Исправление 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, если слишком много неудачных попыток.