Простое решение: JSON с API - только для авторизованных пользователей, для всех остальных - статичный контент, собранный целиком на стороне сервера.
Непростое:Кратко:
Каждый запрос функции API - это
2 запроса к API с получением и исполнением на стороне клиента обфусцированной JS-задачи между ними, и с ограничением по времени между ними от 1 до 3-х секунд:
1-й - подпись запроса к API (или получение публичного ключа) и получение JS-задачи
2-й - получение ответа на запрос к API (если всё верно и
REFERER - разрешён)
Подробно.Загрузка страницы (front):
1. При загрузке страницы, запросом к API (через JS) на стороне API генерируем временный паблик-токен (PUB-TOKEN) и JS-задачу на основе параметров HTTP-протокола (IP,REFERER,etc..).
2 Затем, исполняем JS-задачу и сразу же, обмениеваем PUB-TOKEN через повторный запрос к API (
с помощью полученного от API и обфусцированного JS-кода!) на публичный ключ (API-KEY).
3. API-KEY сохраняем в куках.
ВАЖНО! Срок действия PUB-TOKEN: 1-3 секунды.
*страница появилась в браузере*
Запрос к API:
Подписываем запрос публичным ключом API-KEY конкретно для этого клиента и снова делаем два запроса к API:
1 Отправка данных для проверки обработки запроса и получение JS-кода с временным токеном (PUB-TOKEN). Исполнение JS-кода с параметрами API-KEY, PUB-TOKEN, TIMESTAMP.
2 Отправка результата исполнения JS-кода и получение результата запроса к API.
Важно мониторить:
0. Все невалидные запросы и ПРИЧИНЫ! их возникновения (например, возможно, что из-за скорости соединения придётся компенсировать время жизни PUB-TOKEN, увеличив его до 5-10 секунд)!
1. Все запросы должны быть УНИКАЛЬНЫМИ!
2. Не допускать запросы к повторному использованию.
3. Код задачи на JS на получение публичного ключа или исполнения запросов к API, должен:
- динамически генериться на стороне API и быть уникальным (полиморфизм)
- быть крайне сложным для анализа
- насколько это возможно: проверять, что среда исполнения - это реальный браузер
- быстро исполняться на стороне клиента
