Как усложнить парсинг сайта?

Есть задумка создания сайта и мобильных клиентов под него. Изначально планируется все реализовывать от единого API. То есть и сайт и клиенты работают с одним кодом, реализующим определенный функционал.


Возникает задача максимально усложнить парсинг API и нечистоплотное его использование. Так как одно дело парсить сайт и html, и совершенно другое — готовые урлы с json-ответами.


Серьезные ребята используют такую штуку как ключ для доступа к API. Но в тех же гугл-картах его надо получать разработчику, что нам совершенно не подходит (глупо думать что пользователь с айфоном будет получать какой-то ключ для доступа к приложению). И придется реализовывать механизм автополучения ключа, что напрочь убивает идею с ключами.


Самым лучшим вариантом был бы некий механизм, когда и сайт и мобильный клиент могут доверять некой третьей стороне (в андроиде — гугл, а айфоне — эппл). То есть мобильный клиент как-то соединяется с третьей стороной, они общаются и у третьей стороны появляется подтверждение его реальности. Мобильный клиент сообщает эту информацию нам, мы проверяем ее на третьей стороне и допускаем к api. Но, если честно, не знаю таких механизмов.


Вариант с блокировкой по IP и прочему, конечно, подходит, но это самый очевидный шаг и, возможно, не самый эффективный.
  • Вопрос задан
  • 6820 просмотров
Пригласить эксперта
Ответы на вопрос 6
Мне кажется вы решаете задачу которой нет. Если у вас интересный, полезный контент, который есть смысл парсить, вас ничто не спасёт. В крайнем случае, напишут прокси сервис, который будет парсить хтмл и выдавать json. Вспомните борьбу аськи с квипом. Апдэйт выходил через пару часов, после смены протокола.

Если вы боитесь, что к вашему сайту сделают андроид клиент, то наверное имеет смысл просто сделать сразу свой? А если боитесь альтернативных клиентов, сделайте свой лучше чем альтернативный. Это единственный путь.
Ответ написан
xmoonlight
@xmoonlight
https://sitecoder.blogspot.com
Для мобильных клиентов:
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).

Все варианты конечно же обходятся, но задача значительно усложняется.
Если еще у кого есть более лучшие варианты — с удовольствием почитаю.
Ответ написан
@mihaildemidoff
Может стоит попробовать certificate — based authentication? Он конечно не исключит возможность кражи ключа из андроид приложения, но усложнит задачу на порядок.
Ответ написан
syschel
@syschel
freelance/python/django/backend
Как ещё вариант. Можно антиДДОС защиту поюзать. То есть, если есть много обращений с одного ИП, за короткий промежуток времени, на разные урлы/запросы. Значит не приложение, не человек сайт смотрит, а парсер всё тянет. Можно смело банить.
Ответ написан
asm0dey
@asm0dey
Полностью AJAX-сайт. Типа того, что получается при работе с GWT. Поскольку есть так же обертка gwt-phonegap получите ко сему еще и универсальное мобильное приложение под основные платформы.
Ответ написан
Lerg
@Lerg
Defold, Corona, Lua, GameDev
Для мобильного приложения — шифрование.
Для веб версии тоже что-нибудь бинарное в качестве клиента, тоже с шифрованием.
Flash, Java, Silverlight — похуже (можно разобрать). Chrome Native Client или скачиваемый собственный бинарный плагин для работы с сайтом — получше.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы