Ответы, понравившиеся пользователю terka43

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

rPman @rPman

Основная защита от парсинга - только при доступе к данным по авторизации и установка лимитов на данные (объем, доступный пользователю либо за какой то период времени, например сутки/месяц).

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

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

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

spoiler

* api не должен быть простым и интуитивно понятным, идентификаторы могут вообще не быть постоянными (их можно преобразовывать на бакэнде на основе данных в сессии)
* код javascipt, например получения ссылки на объект должен быть нетривиальным, т.е. чтобы получить следующую ссылку на требуемый граберу объект, потребовалось бы использовать сам браузер (а не простенький скрипт парсер html)
* верстка может быть непостоянной, изменяющиеся, простые гуляющие наименования классов и идентификаторов уже могут создать кучу проблем (я такое встречал), а уж постоянное изменение структуры должно совсем запудрить голову даже опытным граберам (не встречал)
* шрифт может не являться правильным (видимые символы могут не соответствовать их кодам), при этом генерируемый каждый раз новый под конкретную сессию пользователя. Простая подстановка, сильно усложнит (но не сделает невозможной) получение данных через буфер или document.innerText в консоли браузера, оставив граберу только вариант распознавание экрана скринридером (а не тривиальная верстка потребует от пользователя сложную настройку и автоматизацию и эти инструменты)
* типовые javascript методы браузера должны быть замещены на 'неправильно работающие', чтобы граберу пришлось использовать внешние скрипты а не простой инжект javascript (обычно это сильно упрощает).

Войдите на сайт