Вообщем так...щас взял лист бумаги...карандашом расчертил все варианты и со стороны API и со стороны клиента...
Реально защититься на 100% вряд ли выйдет...
rPman, Да дело не в том что, данные УЖЕ ОТДАЛИ...
А в том, чтобы с конкретного шага из API не могли повторить запрос...
Сами данные на каждом шаге (при валидных запросах) постоянно (не очень часто) меняются...но будут умники, которые будут кэшировать, и пытаться пользоваться данными...
При запросе книг этого автора по уникальному айди - ставьте ему отметку «протух». Тогда пусть ваши юзеры пьют чай неделями, айдишка их будет ждать.
Если он обновит страницу с тем же запросом? Если ставить "протух" сразу...
У меня изначально такие мысли были:
1. Генерим "вртуальные ID" авторов примерно таким способом:
- ID автора + токен и зашифровываем во что-то; 2. При запросе по этой зашифрованной строке: - Расшифровываем на своей стороне; - Достаём ID и токен;
- Смотрим "протух" ли токен и: * Если протух, то в ответе API отсылаем новую строку содержащую ID+токен, зашифрованную по алгоритму 1. При этом на стороне клиента должно быть условие, что, если такое произошло, то нужно сделать повторный запрос с новой зашифрованной строкой; * Если НЕ протух, то сразу выдаём данные.
Но мне показалось, что это как-то не по феншую...))
НО, давайте рассмотрим как это будет выглядеть для конечного пользователя(обычного юзера) этим сервисом...
1. Он нажимает авторы;
2. Идёт пить кофе...
3. Тыкает автора...и...обломс?))
НО, если вдруг у тебя что-то выйдёт (написано самим тобой с нуля), то, пожалуйста, создай здесь тему с моим упоминанием на этот пост...я поучаствую в твоём сервисе...и попробуй только потом мне не выплатить то, что я "заработаю" в твоём сервисе... :)
Sanes, Ну всякие там CRUD операции и поля с формами, списки с фильтрами, то же управление ролями...можно и взять из пакета...там сообщество нормальное...
Я когда-то тоже чаще выбирал самопис...но правда в то время и не было нифига особо... :)
Извиняйте...))