Как запретить кеширование данных, полученных через API?
Дано:
Некий API (который нужно разработать) с подчётом кол-ва запросов по некоторым методам этого API...
Условия:
Не дать возможность кэшировать ответы по каждому методу (либо некоторых).
Подробнее:
Давайте представим такую структуру: - Авторы книг;
- Их книги;
- Рассказы (сказки) в этих книгах.
В самом банальном случае API выглядело бы, например, так:
- Метод получения авторов: /getAuthors
Результат: id: 1
name: Вася Пупкин
id: 2
name: Игнат Великий
...
Метод получения книг по автору: /getBooks/{author_id}
Результат: id: 1
name: Рыбалка
id: 2
name: Космос
...
Метод получения рассказов (сказок) по книге: /getStories/{book_id}
Результат: id: 1
name: Как ловить акулу
id: 2
name: Как улететь на Марс
...
Вернёмся к условию задачи:
Необходимо подсчитывать кол-во запросов по каждому методу (тут проблем нет) и не дать возможность закэшировать ответ, например, метода "получения книг по автору", чтобы в дальнейшем не было возможности, раз сохранив ID'шники авторов, напрямую обращаться к этому методу, минуя метод "получения авторов"...
Есть мысли подменять ID'шники с какой-то "солью/хэшем" и т.п...
Но хотелось бы послушать Ваши мысли...потому что до конца картинка не складывается, а костылями не хочется орудовать :)
Мне сам код и как это сделать не нужно...просто ход мыслей и логики нужен для решения подобной задачи...
Вообщем так...щас взял лист бумаги...карандашом расчертил все варианты и со стороны API и со стороны клиента...
Реально защититься на 100% вряд ли выйдет...
Да я сам немного протупил...потому что, если один пользователь смотрит данные на конечном ресурсе какой-то раздел и даёт ссылку другому обычному юзеру на этот раздел, то выйдет фигня))
Это, если не брать во внимание "программиста", который пользуется этим API, чтобы "вывести" эти данные на своём ресурсе...
Исходя из вопроса и у меня и у всех Вас ход мыслей правильный...тыкну решением...вот и всё))
Сделайте айдишки авторов в виде коротких токенов с возможностью дешифровки, и привязывайте их к пользователю, работающему с апи, а также сроком действия - час. Тогда другие пользователи еще и запросить от чужого имени не смогут.
N, мне лень писать повторно, но вы прочитайте свой вопрос и потом мой ответ. Вам надо запретить кеш, но при этом протухание по времени вам не катит. Вам надо заставить людей каждый раз запрашивать айдишки, но опять-таки запрет юзать их после протухания - не катит. Ну сделайте еще проще - генерите айдишки авторов для теущего юзера апи, пишите их в базу. При запросе книг этого автора по уникальному айди - ставьте ему отметку «протух». Тогда пусть ваши юзеры пьют чай неделями, айдишка их будет ждать.
А про jwt - это тут причем? Я предложил вариант подменять реальные айдишки - виртуальными, чтобы иметь возможность применить к ним протухание.
При запросе книг этого автора по уникальному айди - ставьте ему отметку «протух». Тогда пусть ваши юзеры пьют чай неделями, айдишка их будет ждать.
Если он обновит страницу с тем же запросом? Если ставить "протух" сразу...
У меня изначально такие мысли были:
1. Генерим "вртуальные ID" авторов примерно таким способом:
- ID автора + токен и зашифровываем во что-то; 2. При запросе по этой зашифрованной строке: - Расшифровываем на своей стороне; - Достаём ID и токен;
- Смотрим "протух" ли токен и: * Если протух, то в ответе API отсылаем новую строку содержащую ID+токен, зашифрованную по алгоритму 1. При этом на стороне клиента должно быть условие, что, если такое произошло, то нужно сделать повторный запрос с новой зашифрованной строкой; * Если НЕ протух, то сразу выдаём данные.
Но мне показалось, что это как-то не по феншую...))
можно сделать многоразовый токен с ограниченным сроком действия скажем в минуту, выдавайте его по запросу авторов, обновляйте его если страница с авторами открыта раз в минуту, при запросе книг автора - передавайте этот токен и проверяйте его на действительность
НО, давайте рассмотрим как это будет выглядеть для конечного пользователя(обычного юзера) этим сервисом...
1. Он нажимает авторы;
2. Идёт пить кофе...
3. Тыкает автора...и...обломс?))
Пока страница использующая токен открыта в браузере - таймер времени жизни этого токена остановлен, реализация по простому - держать открытое соединение (вебсокет с автопереподключением) при его закрытии запускать таймер.
rPman, ну, тут на самом деле много нюансов. Если токен менять скажем раз в минуту, то злоумышленнику придется и ссылки на книги раскиданные по инету менять раз в минуту. Это в принципе реализуемо на его собственных ресурсах, но совсем не реализуемо на ресурсах третьих лиц. При этом не забываем о проверке на сервере с какого домена пришел запрос.
Еще раз, абсолютно пофиг что вы напридумываете с api, если вы отдали данные - вы над ними уже не властны. Создается промежуточный сервис, который делает запросы и кеширует их самостоятельно, в интернете размещаются уже ссылки на этот сервис, если вам зачем то это надо.
Идентификатором данных может быть не ссылка на вашем сайте а набор действий которые нужно сделать пользователю (в интерфейсе) чтобы добраться до нужной страницы, начиная с некоторой стабильной - например главной.
Максимум вы можете ограничить доступ к данным на пользователя и их количество, выдаваемое в разумный промежуток времени, т.е. к примеру один пользователь, у которого бесплатный тариф позволяет открыть только ограниченное количество данных, а платный - неограничен но лимитирован по скорости их получению. Кстати для бесплатных пользователей вам придется что то делать для ограничения количества регистраций
rPman, Да дело не в том что, данные УЖЕ ОТДАЛИ...
А в том, чтобы с конкретного шага из API не могли повторить запрос...
Сами данные на каждом шаге (при валидных запросах) постоянно (не очень часто) меняются...но будут умники, которые будут кэшировать, и пытаться пользоваться данными...
чтобы в дальнейшем не было возможности, раз сохранив ID'шники авторов, напрямую обращаться к этому методу, минуя метод "получения авторов"...
Таким образом о полном запрете кэшировании речи не идет. А речь идет об одноразовых ссылках.
Соответственно наиболее простым в реализации мне видится такой способ:
1. создается таблица в БД для сохранения токенов и срока их действия, и цели (автор или книга или глава и ее ID) а так же информация о клиенте (в самом простом случае его IP но если делать правильно, то отпечаток клиентского устройства)
2. при генерации страницы с авторами:
- для каждой книги автора генерируется новый одноразовый токен со сроком жизни скажем сутки.
- все ссылки на книгу в текущей генерации страницы автора содержат данный токен (свой для каждой книги)
- в бд вносится токен, дата генерации и цель (автор или книга или глава и ее ID) и отпечаток клиентского устройства
3. с остальными пунктами (книгиб главы) по той же схеме
как это работает:
я захожу на страницу авторов, и все ссылки на книги содержат уникальный одноразовый токен с ограниченным сроком действия, привязанный к данной конкретной записи (автору, книге, главе) а так же привязанный к данному конкретному устройству.
При нажатии на любую ссылку (любого автора) идет запрос на сервер, содержащий и данный токен.
Сервер получая запрос, смотрит в БД наличие данного токена и связанной с ним инфы и если токен есть сравнивает ID автора из ссылки и ID автора взятого из связанной с токеном инфы а так же сравнивает цифровой отпечаток устройства с цифровым отпечатком устройства сохраненном в токене. Если хоть одна из проверок не пройдена, отправляем пользователю страницу "ай-ай-ай)))", если пройдена, выдаем ему список книг автора и удаляем токен из базы. Далее выданный список книг автора работает по той же схеме, и список глав книги тоже. Плюс ко всему раз в N времени подчищаем в базе просроченые токены.
Таким образом по любой из сылок со страницы можно получить информацию только 1 раз, что и требовалось реализовать.
и не дать возможность закэшировать ответ, например, метода "получения книг по автору", чтобы в дальнейшем не было возможности, раз сохранив ID'шники авторов, напрямую обращаться к этому методу, минуя метод "получения авторов"...
Про умников, которые умудряются кешировать данные которые кешировать нельзя, запретить им это делать будет никак нельзя, они же умники.
Если говорить про корявые инструменты, которыми будут пользоваться (например инструмент не смотрит http заголовок Cache-Control: no-cache), то тогда достаточно в правилах к api потребовать чтобы ссылка всегда была разной - к примеру добавляйте в конец атрибут &t=$timestamp и сервер проверяет что ее значение не выходит за какие то рамки.
Роман, Да я сам немного протупил...потому что, если один пользователь смотрит данные на конечном ресурсе какой-то раздел и даёт ссылку другому обычному юзеру на этот раздел, то выйдет фигня))
Это, если не брать во внимание "программиста", который пользуется этим API, чтобы "вывести" эти данные на своём ресурсе...
Исходя из вопроса и у меня и у всех Вас ход мыслей правильный...тыкну решением...вот и всё))
N, тут соглашусь, если програмист с определенной периодичностью сканит весь сайт на предмет составления слепка всей инфы близкого к актуальному, то от этого защититься почти нереально, особенно если он (программист) делает это через разные IP (прокси) и соблюдает некий временной интервал между запросами. В таком случае разве что сильная капча поможет.
Роман, Да это всё понятно...просто надо сделать сервис с одной стороны ОЧЕНЬ ПРОСТЫМ в использовании API, и в той же степени "НЕ ПРОБИВАЕМЫМ"...в данном случае - ФИАСКО... :)
rPman, Да тут ещё вопрос в том, что эти "программисты" будут строить сервисы из этих данных на своих сайтах...а там важно постоянные URL...и заставлять их тоже лепить костыли не вариант...как они будут запрашивать данные по "своим" постоянным URL например?
Нужно было сделать API, чтобы было максимально простым по типу стандартного...
Но я щас порисовал на бумаге все варианты...и сам от себя защититься не смог... :)
N, программистам для их сервисов так же выдавать разовые токены при каждом их запросе на инфу? для них не будет костылей, просто сгенерированная вами ссылка с токеном которую они отображают на своем сервисе (при каждом запросе от пользователей к их сервису они по апи обращаются к вам за порцией данных, которые и будут содержать новые ссылки с одноразовыми токенами)
Роман, Это всё круто...но у них может быть SEO или ещё что-то...где важны ПОСТОЯННЫЕ URL... :)
Я ж не только о себе беспокоюсь...но и об удобстве "злоумышленников"... :)
Роман, Я слежу за темой)) Не переживай) В течение суток максимум всегда отвечу))
Если прям 100%'ное решение родится у Вас, то я попытаюсь родить то, что Вам можно будет в карман положить...))
Но, реально...я лист бумаги разрисовал и сам себя нае**ть не смог)) Если представляю себя в роли того, кто будет пользоваться API...
N, так, подумал вот в каком ключе.
1. мне не хватает информации о том, для чего это вообще надо (как некий абстрактный сервис или по распространяемым данным уже есть конкретика)
2. плясать тут надо не от технической стороны а от рациональной. Объяснение так себе, попробую раскрыть:
- ценность информации не в самой информации а в ее актуальности. т.е. если вы планируете торговать какой либо информацией по подписке через API вашего сервиса или как либо еще, надо защищать не уже проданную информацию, а ее обновления. Другими словами полноценно защищаться от кэширования нет ни смысла ни тех возможности. Лучшая защита это необходимость получения у вас свежей порции актуальной инфы. Отсюда и вопрос из пункта 1. Ответьте на него хотя бы в общих чертах, и можно будет размышлять дальше.
Роман, Вы всё правильно поняли.
Но обновляемая информация происходит раз в сутки (допустим), а сам объём новых данных не факт, что будет отличаться от уже существующих...
Поэтому я и написал, что - ФИИСКО... :)
Но готов и дальше помыслить на этот счёт, если есть идеи))
N, раз в сутки еще терпимо. Ведь даже если будут "кэшировать" все равно зависимость от пуповины (вашего сервиса) никуда не денется. При этом даже если ваши клиенты программеры и будут честны, никто не даст гарантии что их клиенты не напишут парсер уже с их сайта. А по сему вопросы:
- о распространении какой информации идет речь (хотя бы в общих чертах)?
- насколько критично для бизнес плана будет появление в сети обновляемой копии распространяемой инфы скажем недельной свежести? и если критично, то почему?
- возможно ли введение штрафных санкций к тем, у кого слита информация (способы вычислить чью копию слили есть)?
- насколько введение данных санкций на ваш взгляд будет эффективно и почему?
- о распространении какой информации идет речь (хотя бы в общих чертах)?
Тут допустим не важно...реально не могу раскрыть))
- насколько критично для бизнес плана будет появление в сети обновляемой копии распространяемой инфы скажем недельной свежести? и если критично, то почему?
Критично.
Если даже будет копия устаревших данных, то по этим данным можно извлечь выгоду.
- возможно ли введение штрафных санкций к тем, у кого слита информация (способы вычислить чью копию слили есть)?
Вычислением заниматься никому не хочется и некому))
- насколько введение данных санкций на ваш взгляд будет эффективно и почему
Предыдущий ответ))
Грубо говоря так:
От полученных данных через API зависит прибыль пользователей этим API (программистов, если прям грубо)...
А от запросов к этому API зависит прибыль РАЗДАЮЩЕГО это API... :)
Роман, Ну Вы абстрагируйтесь от SEO...
Даже есди представить, что мы не знакомы и, допустим, я на этом сервисе, как конечный пользователь что-то нашёл, и решил скинуть ссылку Вам...
То как должен действовать тот программист, который делает этот сервис через этот API ?
если копаться по сайтам могут только зарегистрированные а делится можно вообще с любыми то у зареганных показывает список чего либо и у каждого пункта есть кнопка [поделится] по нажатию которой генерится разовая ссылка вида https://domain.blabla/hash/7cxc8212x3n872cx
Ну смотри...
Я дал тебе API...
А какие там у тебя пользователи - мне не интересно...))
Понимаешь?)
Ты имеешь отношения со мной.
А твои пользователи - с тобой.
И мне хотелось побеспокоится о ТВОИХ пользователях в конечном итоге, если в идеале...
N, так, давай иначе, я перечислю требования как я их понял, ты проставишь для них да нет.
1. сервис содержит API выдающее некую информацию
2. информация хранится на сервисе в виде данных в БД и файлов
3. ваш сервис содержит собственный вэб интерфейс для предоставления этих данных
4. партнеры должны посредством API получать данные и ссылки на файлы, которыми могут делится через свои сайты
5. каждый партнер полностью свободен в реализации своего сайта
6. ссылки, которые предоставляют партнеры третьим лицам должны вести на сайт партнера
7. ссылки, которые предоставляют партнеры третьим лицам должны вести на ваш сайт
8. при этом ссылки не должны препятствовать SEO
9. при этом вы хотите максимально затруднить автоматизированное создание копии предоставляемой информации для партнеров
10. при этом вы хотите максимально затруднить ручное создание копии предоставляемой информации для партнеров
11. при этом вы хотите максимально затруднить автоматизированное создание копии предоставляемой информации для третьих лиц
12. при этом вы хотите максимально затруднить ручное создание копии предоставляемой информации для третьих лиц
Ответьте ДА/НЕТ там где это возможно, там же где требуется развернутое пояснение сделайте его.
и вот еще
13. партнер в праве кэшировать у себя списковую информацию и предоставлять ссылки на нее на свой сервис
14. партнер в праве кэшировать у себя файловую информацию и предоставлять ссылки на нее на свой сервис
2. информация хранится на сервисе в виде данных в БД и файлов
ДА
3. ваш сервис содержит собственный вэб интерфейс для предоставления этих данных
Тут не совсем понял...мой сервис будет содержать методы API, которые я реализую, как хочу...но при этом должно быть удобно как с "обычным" API (в пределах разумного)...
4. партнеры должны посредством API получать данные и ссылки на файлы, которыми могут делится через свои сайты
Файлов нет. Есть текстовая информация разбитая по "полям" для структуры и удобства вывода.
5. каждый партнер полностью свободен в реализации своего сайта
ДА
6. ссылки, которые предоставляют партнеры третьим лицам должны вести на сайт партнера
ДА
7. ссылки, которые предоставляют партнеры третьим лицам должны вести на ваш сайт
НЕТ
8. при этом ссылки не должны препятствовать SEO
ДА
9. при этом вы хотите максимально затруднить автоматизированное создание копии предоставляемой информации для партнеров
ДА
10. при этом вы хотите максимально затруднить ручное создание копии предоставляемой информации для партнеров
Насчёт именно "ручного" тут пофиг.
11. при этом вы хотите максимально затруднить автоматизированное создание копии предоставляемой информации для третьих лиц
На третьих лиц пофиг...ибо ключевые параметры для дальнейшего взаимодействия будут только у партнёра, но его прибыль зависит от "третьих лиц", а моя от "партнёров"...:)
12. при этом вы хотите максимально затруднить ручное создание копии предоставляемой информации для третьих лиц
Конечный пользователь (любой) что-то ищет через сайт партнёра...по поим методам API...
Мне, грубо говоря, пофиг, поимеет ли какой-то профит мой партнёр с этих пользователей...
НО, мне нужно знать, сколько было запросов через эти методы...
А, если эти методы кэшировать будет тот партнёр...то я теряю выгоду...
3. ваш сервис содержит собственный вэб интерфейс для предоставления этих данных
Имеется виду что помимо API вы содержите и сайт с интерфейсом для доступа к данным через браузер
Ну у партнёра есть личный кабинет...там всё учитывается...к API никак не привязать...кроме как самого этого партнёра...
Т.е.:
1. Есть какой-то кабинет партнёра;
2. Ему даётся API;
3. Мы знаем кому дали API;
4. Дальше, если учесть все условия...мы терпим ФИАСКО... :)
N, ок, тогда так. Главный затык, по сути это п.9 и п.13. Все остальное реализуемо посредством API.
Полноценных вариантов не вижу, но есть пару полумер, позволяющих затруднить п.9. первый вариант
Вы делаете не только API но и некоторую встраиваемую в браузер библиотеку, которая будет являтся программным интерфейсом к вашему API, так же данная библиотека должна иметь функционал для заполнения нужной информацией указанный блок/блоки. Тоесть по запросу к API через нее она не выдает json (или любой другой формат) с данными, а самостоятельно эти данные вносит в указанных создателем партнерского сайта блок/блоки. При этом библиотека должна пройти жесткую обфускацию для того чтобы максимально затруднить реверсинженеринг. API сервиса, для того чтобы затруднить перехват информации на стадии доставки до клиента с помощью сниферов должно передавать данные в зашифрованном виде а библиотека должна обеспечивать дешифровку этих данных.
API сервиса, для того чтобы затруднить определение своих роутеров, должно обеспечивать некоторое маскирование роутеров (например все запросы идут не на https://site/authors/get а на некий, одноразовый https://site/jdhf74cbfd7fwfue4) Это достигается следующим образом: клиентская библиотека должна загружаться с вашего сервиса, и при этом при каждой загрузке в нее встраивается временная информация о уникальных, временных псевдонимах вида https://site/jdhf74cbfd7fwfue4 для каждого роутера вашего сервиса, на само же сервисе временно создаются роутеры, соответствующие псевдонимам. Данную механику проще организовать на WS нежели на http.
Все эти меры в совокупности серьезно затруднят реверс инженеринг библиотеки и исследование структуры роутеров вашего сервиса, тем самым максимально затруднят написание автоматизированной системы выкачивания данных из вашего сервиса.
Пример использования такой библиотеки на клиенте[сайт партнера] (достаточно убогий, призванный лишь продемонстрировать подход)
Пусть serviceAPI - это данная библиотека
Пусть serviceAPI.getData(source, targets); - метод, получающий данные от API сервиса
например мы хотим получить список авторов который приходит в виде json следующего содержания (данный json не попадает в доступ к партнеру, но его структура описана и ему известна)
const authors = serviceAPI.getData("authors");
authors.insert("head", "id блока в который засунуть инфу");
authors.foreach("list", (item)=>{
// тут партнер создает блоки для размещения инфы об очередном авторе и заполняет их
item.insert("name", "id блока для имени");
item.insert("info", "id блока для инфы");
item.link("id", "id блока для создания ссылки");
});
то есть объекты типа authors и item содержат методы:
.insert("наименование ключа", "id блока для вставки данных из данного ключа");
.foreach("наименование ключа", (item)=>{
// функция получающая для каждой записи из массива "наименование ключа" объект item, имеющий те же методы что и authors а так же доступ к полям/ключам текущего автора/или чего еще
});
.link("наименование ключа", "id блока для создания ссылки");
все эти методы весьма условны и плохо прдуманы (а как же react, angular и vue), просто демонстрация подхода.
Основная их цель не дать партнеру доступа к данным, но при этом позволить разместить эти данные на странице в подготовленных партнером блоках (div-ах).
таким образом, партнер не имеет прямого доступа к информации, но может размещать ее на своем сайте, оформляя блоки так как ему нравится
Данный подход не защитит информацию полностью, достаточно упорный программер сможет написать парсер, вытягивающий ее прямо из блоков, но все же сильно затруднит парсинг инфы
Прочитал. Идея хорошая. Но идеально чтобы на стороне сервера только что-то сделать. Потому что тем же партнёрам будет сложно всё это объяснять и заставлять так плясать с бубном вокруг каждого сайта))
Они просто не станут этим тогда пользоваться и тут я опять теряю выгоду :)
N, любые манипуляции на стороне сервера не пресекут возможность получить и сохранить информацию.
На самом деле поразмышляв всетаки скажу что вышеизложенная идея плоха, так как опять же не пресекает возможность распарсить готовый html.
В общем пришел к выводу, чтл в заданных условиях технического решения (даже компромисного) не найти.
Остается только продавать инфу за такую цену, чтобы ее кеширование и перепродажа не несла убытков. А это плохо, не каждый купит. Ну еще можно продовать инфу блоками (заплатил - купил новый блок инфы). Другого на ум не приходит.
Простой
