Как защитить контент от парсинга с помощью Nginx?

Добрый день!
Можно ли защитить контент от парсинга, если папки клиента именованы как id пользователя? К примеру проверка по токену или папки по алиасу?
  • Вопрос задан
  • 1042 просмотра
Решения вопроса 1
@rPman
Основная защита от парсинга - только при доступе к данным по авторизации и установка лимитов на данные (объем, доступный пользователю либо за какой то период времени, например сутки/месяц).

Анонимно доступные данные, в общем случае, защитить от выгрузки пользователями - невозможно. Все что пользователь видит на экране можно тупо скопировать и проанализировать.

В некоторых случаях, если собирать качественный отпечаток браузера, можно присвоить анонимным пользователям некий идентификатор и уже на его основе выставить на бакэнде лимиты доступа к данным, но как всегда трудности в мелочах и если перестараться, можно помешать работе легитимных пользователей.

Можно поставить 'палки в колеса', сделав этот процесс сложнее (и дороже), в основном это запутывание/шифрование данных, доступных напрямую (по api) с бакэнда и обфускация кода, его преобразования в видимый пользователю контент, чтобы классические (дешевые) инструменты не работали. Как всегда стоимость защиты (затрат на разработку) должна быть сравнима затрат граберов на получение данных (обычно им проще).
К сожалению вместе с контент-грабером, в заблуждение будут введены роботы поисковых систем, ведь их основная работа - грабить контент.
spoiler
* api не должен быть простым и интуитивно понятным, идентификаторы могут вообще не быть постоянными (их можно преобразовывать на бакэнде на основе данных в сессии)
* код javascipt, например получения ссылки на объект должен быть нетривиальным, т.е. чтобы получить следующую ссылку на требуемый граберу объект, потребовалось бы использовать сам браузер (а не простенький скрипт парсер html)
* верстка может быть непостоянной, изменяющиеся, простые гуляющие наименования классов и идентификаторов уже могут создать кучу проблем (я такое встречал), а уж постоянное изменение структуры должно совсем запудрить голову даже опытным граберам (не встречал)
* шрифт может не являться правильным (видимые символы могут не соответствовать их кодам), при этом генерируемый каждый раз новый под конкретную сессию пользователя. Простая подстановка, сильно усложнит (но не сделает невозможной) получение данных через буфер или document.innerText в консоли браузера, оставив граберу только вариант распознавание экрана скринридером (а не тривиальная верстка потребует от пользователя сложную настройку и автоматизацию и эти инструменты)
* типовые javascript методы браузера должны быть замещены на 'неправильно работающие', чтобы граберу пришлось использовать внешние скрипты а не простой инжект javascript (обычно это сильно упрощает).
Ответ написан
Пригласить эксперта
Ответы на вопрос 3
samodum
@samodum
Какой вопрос - такой и ответ
Не нужно вешать на nginx задачу защиты от парсинга, он не для этого создан.
Защищаться надо собственными силами на бэке
Ответ написан
Комментировать
nokimaro
@nokimaro
Меня невозможно остановить, если я смогу начать.
Могу порекомендовать доклад от 2GIS и их вариант с написанием lua-модуля для nginx (opernresty)
https://www.youtube.com/watch?v=pYxnW7kYcbU

Доклад как минимум полезен тем, что там есть полезная информация о том как выявлять парсеры и что с этим делать.
Ответ написан
Комментировать
@quiex
Коротко - никак.
Ответ написан
Комментировать
Ваш ответ на вопрос

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

Похожие вопросы