Есть задумка создания сайта и мобильных клиентов под него. Изначально планируется все реализовывать от единого API. То есть и сайт и клиенты работают с одним кодом, реализующим определенный функционал.
Возникает задача максимально усложнить парсинг API и нечистоплотное его использование. Так как одно дело парсить сайт и html, и совершенно другое — готовые урлы с json-ответами.
Серьезные ребята используют такую штуку как ключ для доступа к API. Но в тех же гугл-картах его надо получать разработчику, что нам совершенно не подходит (глупо думать что пользователь с айфоном будет получать какой-то ключ для доступа к приложению). И придется реализовывать механизм автополучения ключа, что напрочь убивает идею с ключами.
Самым лучшим вариантом был бы некий механизм, когда и сайт и мобильный клиент могут доверять некой третьей стороне (в андроиде — гугл, а айфоне — эппл). То есть мобильный клиент как-то соединяется с третьей стороной, они общаются и у третьей стороны появляется подтверждение его реальности. Мобильный клиент сообщает эту информацию нам, мы проверяем ее на третьей стороне и допускаем к api. Но, если честно, не знаю таких механизмов.
Вариант с блокировкой по IP и прочему, конечно, подходит, но это самый очевидный шаг и, возможно, не самый эффективный.
Парсинг html для перловика средней руки это 1 рабочий день — если он был пьян, а ваши верстальщики и разработчики невменяемые идиоты, которые делают ужасный код, и часы, а то и минуты если он трезв, и ваш html код более-менее вменяем.
Так что вы вложите в попытки обфускации много ресурсов, а вскорют ее за 1 день, или пару сотен баксов на фрилансерском сайте.
Никакого технического способа определить кто на той стороне — хакер или честный пользователь не может быть в принципе. Выдадите сертификат — чудесно, этот сертификат и используют в боте. Любые подобные меры тривиально обходятся.
Максимум что вы можете сделать — создать мелкий геморрой, не давая доступа к API тем юзерам, которые не оплатили, а также лимитировав количество запросов с одного IP. Но все это все равно проблему не решает (про историю с аськой все отлично тут уже сказали)
Мне кажется вы решаете задачу которой нет. Если у вас интересный, полезный контент, который есть смысл парсить, вас ничто не спасёт. В крайнем случае, напишут прокси сервис, который будет парсить хтмл и выдавать json. Вспомните борьбу аськи с квипом. Апдэйт выходил через пару часов, после смены протокола.
Если вы боитесь, что к вашему сайту сделают андроид клиент, то наверное имеет смысл просто сделать сразу свой? А если боитесь альтернативных клиентов, сделайте свой лучше чем альтернативный. Это единственный путь.
Я предполагал подобные ответы, но руководством четко поставлена задача — на этапе планирования предусмотреть by design фичу защиты контента. Задача есть и давайте остановимся на этом. Задача интересная, и вопрос не в защите как таковой, а в максимальном усложнении. Я прекрасно понимаю, что спарсить можно все.
Так и объясните руководству, что спарсить можно всё и что это напрасная трата времени.
PS да даже, если каким-то чудом вы усложните парсинг на столько, что его весьма затратно будет спарсить, никто не мешает одну/армию «обезьянок» посадить которая просто будет переписывать текст с экрана (как это сделали с капчёй).
Задача не предотвратить парсинг, а усложнить в условиях, когда мобильный клиент получает чистый json. И если на сайте можно еще поиграться со всякими там скрытыми картинками, js, то тут мы физически не можем это сделать. И вопрос только в доверии — хороший это клиент или плохой.
Ну введите частоту запросов, плюс берите ваш json в бинарный вид и перемешивайте с гаммой, беря в качестве нее номер дня недели. Это защити вас от тупых, но все равно для расшифровки протокола, достаточно деобфуцировать js на сайте.
Учитывая что в любом случае алгоритм дешифровки лежит в js в открытом виде, дальнейшее его усложнение не целесообразно
Для мобильных клиентов:
1. После запуска приложения — cобираете информацию об устройстве и вашем клиенте (hash-тела, к примеру), шифруете, передаете к себе.
2. На сервере: выписываете ключ доступа именно для этого устройства, формируете salt и сохраняете в БД, возвращаете алгоритм формирования ключа клиенту с примесью salt и временную засечку.
3. Клиент каждый раз при запросе API формирует подпись на основе salt, инф. об устройстве и клиенте (hash-тела).
Если подпись верна и время ответа было менее TIMEOUT, то доступ к API разрешается.
Для WEB (при каждом вызове страницы, где есть взаимодействие с API):
1. Запрос страницы с сервера: сохраняем на сервере: key1, отпечаток времени, контент отправленной страницы клиенту
2. Скрипт клиента со страницы грузит по ajax функцию для вычисления key2 на основе всего исходника страницы используя key1 и сразу же возвращает вычисленное значение (key3) на сервер.
3. На сервере — проверка key3, и если время ответа было менее TIMEOUT, то сервер разрешает доступ к API (обращение к API подписывается key3).
Все варианты конечно же обходятся, но задача значительно усложняется.
Если еще у кого есть более лучшие варианты — с удовольствием почитаю.
Что мешает перенести все эти сложные подписи ключами в бота? Чего вы добъетесь кроме псевдо идентификации пользователей, которая обходится запуском параллельно большого числа ботов, работающих через прокси.
Ну минимум то, что мне сменить автоматом алгоритм проверки на сервере в несколько раз проще, чем Вам постоянно корректировать скрипт бота (или своего клиента, чтобы он всегда оставался рабочим).
Longer, вопрос во времени. Я буду генерить код динамически и налету, а альтернативного клиента — придется постоянно править руками. Здесь про аську — вообще не в тему… Они у себя тоже меняли руками (на серверной стороне). При эффекте неожиданности (смена протокола с привязкой ко времени) с проверкой времени на ответ (TIMEOUT) сложность создания альтернативного клиента можно увеличивать до бесконечности.
javascript отнюдь не панацея — есть же phantomjs с вебкитом, или кластер с selenium с чем угодно. обычно используют для функционального тестирования, но думаю, что можно приспособить и для парсинга.
Может стоит попробовать certificate — based authentication? Он конечно не исключит возможность кражи ключа из андроид приложения, но усложнит задачу на порядок.
Как ещё вариант. Можно антиДДОС защиту поюзать. То есть, если есть много обращений с одного ИП, за короткий промежуток времени, на разные урлы/запросы. Значит не приложение, не человек сайт смотрит, а парсер всё тянет. Можно смело банить.
Полностью AJAX-сайт. Типа того, что получается при работе с GWT. Поскольку есть так же обертка gwt-phonegap получите ко сему еще и универсальное мобильное приложение под основные платформы.
Для мобильного приложения — шифрование.
Для веб версии тоже что-нибудь бинарное в качестве клиента, тоже с шифрованием.
Flash, Java, Silverlight — похуже (можно разобрать). Chrome Native Client или скачиваемый собственный бинарный плагин для работы с сайтом — получше.
В любом случае веб версия будет явным извращением, так что можно просто забить на это.
Или предоставлять на сайте либо обрезанный материал, либо устаревший, а в мобильном приложении — полный доступ.
Простой
