{"id":14262,"url":"\/distributions\/14262\/click?bit=1&hash=8ff33b918bfe3f5206b0198c93dd25bdafcdc76b2eaa61d9664863bd76247e56","title":"\u041f\u0440\u0435\u0434\u043b\u043e\u0436\u0438\u0442\u0435 \u041c\u043e\u0441\u043a\u0432\u0435 \u0438\u043d\u043d\u043e\u0432\u0430\u0446\u0438\u044e \u0438 \u043f\u043e\u043b\u0443\u0447\u0438\u0442\u0435 \u0434\u043e 1,5 \u043c\u043b\u043d \u0440\u0443\u0431\u043b\u0435\u0439","buttonText":"\u041f\u043e\u0434\u0440\u043e\u0431\u043d\u0435\u0435","imageUuid":"726c984a-5b07-5c75-81f7-6664571134e6"}

Простая инструкция как защитить свой сайт или интернет-магазин от парсинга

Советы, которые позволят максимально сократить "паразитный" трафик.

Несмотря на то, что моя компания XMLDATAFEED профессионально занимается парсингом уже более 3х лет и ежедневно парсим порядка 400 крупнейших сайтов РФ, мы часто сталкиваемся с просьбами наших клиентов помочь в противодействии парсингу их ресурсов.

Да, это звучит немного странно, особенно учитывая тот факт, что клиенты знают что мы часто и их сайты парсим (мы это никогда не скрываем), но наш опыт в парсинге иногда помогает сделать их защиту лучше, т.к. в 80% случаев их парсят не профессионалы, а "студенты", которые в массе своей учатся этому делу, создают очень высокую паразитную нагрузку и не готовы заниматься серьезным анализом обхода защиты (исповедуют принцип "сила солому ломит" и включают в 50 потоков сбор данных).

Советы ниже не являются 100% панацеей от парсинга, но могут настолько усложнить "жизнь" парсерам (особенно неофитам в этом деле), что встанет вопрос о целесообразности продолжения этого дела. Плюс, скорость парсинга тоже имеет значение (особенно в товарной сфере) и если у вас на 1 товар будет уходить, условно говоря, 20 секунд, то ценность сбора данных за 2-3 недели вызывает вопросы. Мы стараемся получать данные по Интернет- магазинам не чаще чем 1 товар в 3-4 секунды (это быстрее анализа человеком, но при этом не создает невыносимую нагрузку на сервера).

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

К сожалению, это довольно трудная задача, т.к. необходимо найти компромисс между защитой от парсеров и сложностью доступа для реальных пользователей и поисковых систем.

Чтобы противостоять парсингу (также известному так же как веб-парсинг, веб-анализ данных, веб-сканер или извлечение веб-данных), необходимо понять, как работают парсеры.

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

По сути, существуют различные типы парсеров, и каждый работает по-своему:

  • Поисковые боты, такие как бот Google, или “копиры” веб-сайтов, такие как HTtrack. Они посещают ваш сайт и рекурсивно переходят по ссылкам на другие страницы для получения данных. Иногда они используются при целенаправленном парсинге для получения конкретных данных, часто в сочетании с анализатором HTML для извлечения нужных данных с каждой страницы.
  • Сценарии командной строки: иногда для парсинга используются общие инструменты Unix: Wget или Curl для загрузки страниц и Grep (Regex) для извлечения нужных данных, обычно с использованием сценариев командной строки. Это самый простой тип парсера, а также самый неустойчивый (никогда не пытайтесь анализировать HTML с помощью регулярных выражений! :). В общем, это самый легкий для блокировки вид парсера.
  • HTML-сканеры и парсеры, основанные на Jsoup, Scrapy, а также множество других. Как и в сценариях с использованием командной строки на основе регулярных выражений, они работают, извлекая данные из ваших страниц на основе шаблонов в вашем HTML, при этом игнорируя все остальное.

Например: если на вашем сайте есть функция поиска, такой парсер может отправить HTTP-запрос для поиска (например, подставить название товара - мы так част делаем), а затем получить все ссылки на результаты и их заголовки с HTML-страницы поисковой выдачи, иногда срабатывая сотни раз для сотен различных поисков, чтобы получить именно результаты поиска ссылок и их заголовки. Вот самые распространенные примеры:

  • Парсеры экрана, собранные на Selenium или PhantomJS, фактически открывают ваш сайт в реальном браузере, запускают JavaScript, AJAX и т.д, а затем получают желаемый текст с веб-страницы. Как правило, они действуют одним из следующих способов:Получение HTML-кода из браузера после загрузки вашей страницы и запуска JavaScript, а затем использование анализатора HTML для извлечения нужных данных или текста. Такие парсеры являются наиболее распространенными, и поэтому против них работают многие методы для защиты от HTML-парсеров/сканеров.Сохранение снимков отрендеренных страниц, а затем использование оптического распознавания символов для извлечения нужного текста. Такой способ применяется крайне редко и только специализированными парсерами, которым действительно нужны ваши данные (но все это будет медленно, стоит отметить).

С парсерами на основе браузера сложнее иметь дело, поскольку они запускают скрипты, визуализируют HTML и могут вести себя как настоящий человек, просматривающий ваш сайт.

  • Парсинг-сервисы, например ScrapingHub или Kimono. На самом деле, существуют люди, чья работа заключается в том, чтобы выяснить, как парсить ваш сайт и извлечь контент для использования третьими лицами. Они используют обширные сети прокси-серверов и постоянно меняющиеся IP-адреса, чтобы обойти ограничения и блокировки, поэтому защититься от них особенно проблематично.

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

  • Интеграция вашего сайта в страницы других сайтов с помощью фреймов или встраивание его в мобильные приложения.

Хотя технически это не является парсингом, но это всё равно проблема, поскольку мобильные приложения (Android и iOS) могут встраивать ваш сайт и даже внедрять пользовательские CSS и JavaScript, таким образом полностью изменяя внешний вид сайта и отображая только нужную информацию, такую как сам контент статьи или список результатов поиска, а также скрывать верхние и нижние колонтитулы или рекламу.

  • Человек копирует и вставляет: люди будут копировать и вставлять ваш контент, чтобы использовать его в другом месте. К сожалению, вы ничего не можете с этим поделать.

Хоть и существуют различные типы парсеров, тем не менее, у них есть много общего. Многие парсеры будут вести себя одинаково, даже если они используют разные технологии и методы для получения вашего контента.

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

Как обнаружить и остановить парсинг?

Некоторые общие методы обнаружения и ограничения парсеров:

Следите за своими логами и статистикой трафика; ограничивайте доступ, при обнаружении подозрительной активности:

Регулярно проверяйте логи и, в случае подозрительной активности, свидетельствующей об автоматическом доступе (парсинге, например), множестве запросов с одного и того же IP-адреса, блокируйте или ограничивайте доступ.

Вот некоторые идеи:

  • Ограничение трафика:

Разрешить пользователям (и парсерам) выполнять ограниченное количество действий за определенный промежуток времени. Например, разрешать только несколько поисковых запросов в секунду с одного IP-адреса или от одного пользователя. Это замедлит работу парсеров и существенно снизит их эффективность. Если действия выполняются слишком быстро или быстрее, чем действует реальный пользователь, то можно предложить решить капчу.

  • Выявление подозрительной активности:

Если вы засекли необычную активность — много схожих запросов с одного IP-адреса, кто-то просматривает чрезмерное количество страниц или отправляет большое количество поисковых запросов, вы можете заблокировать доступ или показать капчу для последующих запросов.

  • Не ограничивайтесь идентификацией только лишь по IP-адресу — используйте и другие индикаторы:

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

  • Скорость заполнения формы пользователем и место нажатия на кнопку;
  • С помощью JavaScript вы можете собрать много информации, такой как размер / разрешение экрана, часовой пояс, установленные шрифты и т.д. Всё это можно использовать для идентификации пользователей.
  • Заголовки Http и их порядок, в особенности User-Agent.

Например, если вы получаете много запросов с одного IP-адреса, все используют один и тот же User-Agent, размер экрана (определяется с помощью JavaScript), и пользователь (в данном случае парсер) всегда нажимает на кнопку одинаково и с регулярными интервалами, то очевидно, что это парсер, и вы можете временно заблокировать подобные запросы (например, блокировать все запросы с этим пользовательским агентом и размером экрана, приходящим с этого конкретного IP-адреса), и, таким образом, вы не будете доставлять неудобства реальным пользователям, которые находятся на этом IP-адресе, как бывает при общем подключении к интернету.

Можно пойти дальше: вы можете выделить похожие запросы, даже если они поступают с разных IP-адресов, что указывает на распределенный парсинг (парсер, использующий ботнет или сеть прокси-серверов). Если вы получаете много идентичных запросов, но они приходят с разных IP-адресов, их все можно заблокировать. Опять же, имейте в виду, что всегда есть риск блокировать реальных пользователей.

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

Смежные вопросы по Security Stack Exchange:

Самая простая реализация ограничения трафика — блокировка доступа на определенное время, однако капчу можно использовать эффективнее, см. ниже раздел «Капчи».

Требуйте регистрации и входа

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

  • Если вы требуете создать учетную запись и войти в систему, вы можете отслеживать действия пользователя и парсера. Таким образом, вы можете легко определить, когда конкретная учетная запись используется для парсинга, и заблокировать ее. Ограничить трафик или обнаружить подозрительную активность (например, огромное количество поисковых запросов за короткое время), будет проще, поскольку вы сможете идентифицировать именно парсеры, а не только IP-адреса.

Чтобы избежать заскриптованной регистрации множества учетных записей, вам необходимо:

  • Требовать адрес электронной почты для регистрации и проверять его, отправив ссылку, переход по которой активирует учетную запись. Разрешить регистрировать только одну учетную запись на один адрес электронной почты.
  • Требуйте решения капчи при регистрации/создании учетной записи.

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

Блокируйте доступ с IP-адресов облачного хостинга и парсинг-сервисов

Иногда парсеры запускаются из служб веб-хостинга, таких как Amazon Web Services, Google App Engine или VPS. Ограничьте доступ к вашему веб-сайту (или поставьте капчу) для запросов, исходящих с IP-адресов таких хостингов. Вы также можете заблокировать доступ с IP-адресов парсинг-сервисов.

Аналогично, вы также можете ограничить доступ с IP-адресов, используемых прокси-провайдерами или провайдерами VPN, так как парсеры могут использовать такие прокси-серверы во избежание обнаружения.

Помните, что, блокируя доступ с прокси-серверов и VPN, вы будете негативно влиять на реальных пользователей.

При блокировке, ваше сообщение об ошибке не должно быть информативно для парсера

Если вы блокируете/ограничивает доступ, вам следует убедиться, что вы не сообщаете парсеру, чем именно вызвана блокировка, тем самым давая подсказки о том, как можно модифицировать парсер. Плохой идеей будет показывать страницы ошибок с текстом вроде:

  • Слишком много запросов с вашего IP-адреса, повторите попытку позже.
  • Ошибка, заголовок User Agent отсутствует!

Вместо этого покажите дружелюбное сообщение об ошибке, которое не сообщит парсеру, чем именно он себя выдал. Например так:

  • Извините, что-то пошло не так. Вы можете связаться со службой поддержки через [email protected], если проблема не устранена.

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

Используйте капчи, если вы подозреваете, что к вашему сайту обращается парсер

Капчи (CAPTCHAs, «полностью автоматизированные тесты для распознания компьютеров и людей») очень эффективны против парсеров. К сожалению, они также очень эффективны для раздражения ваших пользователей.

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

Что нужно знать при использовании капчи:

  • Нет необходимости самостоятельно разрабатывать капчи. Воспользуйтесь reCaptcha от Google ‒‒ это намного проще и удобнее для пользователя, чем какое-то размытое и искаженное текстовое решение, которое вы можете придумать самостоятельно (пользователям часто нужно только поставить галочку). Для парсера такая капча намного сложнее, чем простое изображение с вашего сайта.
  • Не включайте решение для капчи в разметку HTML ‒‒ мы видели один сайт, который имел решение для капчи на самой странице (хотя и довольно хорошо скрытое), что делало её довольно бесполезной. Не стоит делать что-то подобное. Опять же, используйте сервис а-ля reCaptcha, и у вас не будет таких проблем (при условии его правильного использования).
  • Капчи могут быть решены массово: существуют сервисы по решению капчей, где реальные люди за низкую плату решают капчи. Опять же, использование reCaptcha является хорошей идеей, поскольку у них есть защита (например, относительно короткое время, которое пользователь имеет для того, чтобы решить капчу). Такой вид сервиса вряд ли будет использоваться, если только ваши данные не являются действительно ценными.

Подавайте текстовый контент в виде изображения

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

Однако это плохо для программ чтения с экрана, поисковых систем, производительности и почти всего остального. Также это незаконно в некоторых странах (из-за ограничения доступности, например, закона об американцах-инвалидах). Такой способ защиты легко обойти с помощью OCR, так что не стоит его использовать.

Не раскрывайте свой полный набор данных:

Если возможно, не предоставляйте скрипту/боту возможность получить разом все ваши данные. Например: у вас есть новостной сайт с множеством отдельных статей. Вы можете сделать эти статьи доступными только путем их поиска через поиск по сайту, и, если у вас нет списка всех статей на сайте и их URL-адресов, эти статьи будут доступны только с помощью поиска. Это означает, что парсер, желающий получить все статьи с вашего сайта, должен будет выполнить поиск всех возможных фраз, которые могут появиться в ваших статьях, чтобы найти их все, что будет занимать много времени, ужасно неэффективно и, будем надеяться, заставит парсер отступить.

Это будет неэффективно, если:

  • Бот/скрипт не нуждается в полном наборе данных.
  • Ваши статьи обслуживаются с URL-адреса, который выглядит примерно так example.com/article.php?articleId=12345. Этот адрес (и подобные ему адреса) позволит парсерам просто перебирать все articleIds и, таким образом, запрашивать все статьи.
  • Существуют и другие способы найти все статьи, например, написать скрипт для перехода по ссылкам внутри статей, которые ведут к другим статьям.
  • Поиск что-то вроде «и» или «а» может выявить почти все, так что об этом нужно знать. (Вы можете избежать этого, только вернув по запросу 10 или 20 результатов).
  • Вам необходимы поисковые системы для поиска вашего контента.

Скрывайте свои API, endpoints и тому подобное:

Убедитесь, что вы, даже непреднамеренно, не выставляете какой-либо API. Например, если вы используете AJAX или сетевые запросы из Adobe Flash или Java-апплетов (не дай Бог!), то для загрузки ваших данных достаточно просто просмотреть сетевые запросы со страницы и выяснить, куда они направлены, а затем перепроектировать их и использовать эти конечные точки (endpoints, рабочие станции и другие конечные точки своей сети) в программе парсера. Убедитесь, что вы обфусцируете свои endpoints и затрудняете их использование другими.

Противодействие парсерам и сканерам

Учитывая, что HTML-парсеры при извлечении контента опираются на идентифицируемые шаблоны в HTML, можно преднамеренно менять эти шаблоны, чтобы сломать парсеры или запутать их. Большинство из этих советов также актуальны для поисковых “пауков” и инструментов захвата экрана.

Чаще меняйте HTML-код

Парсеры, которые напрямую обрабатывают HTML, извлекают содержимое из определенных идентифицируемых частей вашей HTML-страницы. Например: если все страницы на вашем сайте имеют div-идентификатор article-content с текстом статьи, то для получения текста всех статей с вашего сайта достаточно написать скрипт для посещения всех страниц статьи на вашем сайте и извлечь текст содержимого article-content div с каждой страницы статьи.

Если вы часто меняете HTML и структуру своих страниц, такие парсеры могут не сработать.

  • Вы можете часто изменять идентификаторы и классы элементов в своем HTML, причем автоматически. Так что, если ваш div.article-content превращается во что-то вроде div.a4c36dda13eaf0 и меняется каждую неделю, парсер сначала будет работать нормально, но через неделю сломается. Обязательно меняйте длину ваших идентификаторов/классов, иначе парсер будет использовать div.[any-14-characters] для поиска нужного элемента. Остерегайтесь других подобных дыр.
  • Если невозможно найти желаемый контент по структуре разметки, парсер сделает это по структуре всего HTML-кода. Если все ваши страницы статьи сделаны по одному такому шаблону, что каждый div внутри div, который идет после тега h1, является содержимым статьи, то на на основе этого парсеры легко получат содержимое статьи. Опять же, чтобы избежать этого, вы можете добавлять/удалять дополнительную разметку вашего HTML, периодически и случайно. Например, добавление дополнительных divs или spans. При современной обработке HTML на стороне сервера это не составит большого труда.

Однако не следует забывать:

  • Такой процесс будет сложно реализовать, поддерживать и отлаживать.
  • Вы будете мешать процессу кэшированию. Особенно, если вы измените идентификаторы или классы ваших элементов HTML, это потребует соответствующих изменений в ваших файлах CSS и JavaScript. А, значит, они будут повторно загружаться браузером после каждого изменения. Это приведет к увеличению времени загрузки страницы для повторных посетителей и увеличению нагрузки на сервер. Впрочем, если вводить такие изменения раз в неделю, то это не доставит больших проблем.
  • "Умные" парсеры все равно смогут получить ваш контент, сделав вывод, где фактически находится содержимое. Например, предполагая, что большой отдельный блок текста на странице, вероятно, является настоящей статьей, можно находить и извлекать нужные данные со страницы. Boilerpipe делает именно так.

По сути, убедитесь, что для скрипта не так просто будет найти настоящее содержимое для каждой подобной страницы.

Смотрите также: Как запретить сканерам, зависящим от XPath, получать содержимое страницы, и узнайте, как это можно реализовать на PHP.

Меняйте HTML-код в зависимости от местоположения пользователя

В принципе, это совет похож на предыдущий. Использование разного HTML-кода для разного местоположения (определяется по IP-адресу) нарушит работу парсеров. Например, если кто-то пишет мобильное приложение, которое собирает данные с вашего сайта, то в начале оно будет работать нормально. Но? как только приложение окажется у реальных пользователей, в его работе тут же возникнут неполадки, поскольку эти пользователи могут находиться в разных странах и, таким образом, получать разный HTML, который встроенный парсер не поддерживает.

Часто меняйте свой HTML, активно “запутывайте” парсеры

Пример: на вашем веб-сайте есть функция поиска example.com/search?query=somesearchquery, которая возвращает следующий HTML-код:

< div class =”search-result”>

<h3 class=”search-result-title”>Stack Overflow стал самым популярным в мире веб-сайтом для вопросов и ответов по программированию</h3>

<p class=”search-result-excerpt”>В настоящее время веб-сайт Stack Overflow стал самым популярным веб-сайтом для вопросов и ответов по программированию, в котором содержится 10 миллионов вопросов и множество пользователей, которые …</p>

<a class”search-result-link” href=”/stories/stack-overflow-has-become-the-most-popular”>Подробнее</а>

</div>

(И далее множество идентично структурированных div с результатами поиска.)

Как вы уже догадались, такие данные легко извлечь: все, что нужно сделать парсеру — это нажать на URL-адрес поиска с помощью запроса и извлечь нужные данные из возвращенного HTML-кода. В дополнение к периодическому изменению HTML, как описано выше, вы также можете оставить старую разметку со старыми идентификаторами и классами, скрыть ее с помощью CSS и заполнить ее ложными данными, тем самым запутав парсер. Вот как можно изменить страницу результатов поиска:

<div class=”the-real-search-result”>

<h3 class=”the-real-search-result-title”>Stack Overflow стал самым популярным в мире веб-сайтом для вопросов и ответов по программированию </h3>

<p class=”the-real-search-result-excerpt”>В настоящее время веб-сайт Stack Overflow стал самым популярным веб-сайтом для вопросов и ответов, в котором содержится 10 миллионов вопросов и много пользователей, которые … </p>

<a class”the-real-search-result-link” href=”/stories/stack-overflow-has-become-the-most-popular”>Подробнее</a>

</div>

<div class=”search-result” style=”display:none”>

<h3class=”search-result-title”>Посетите example.com сейчас, чтобы узнать все последние новости, связанные со Stack Overflow!</h3>

<p class=”search-result-excerpt”>EXAMPLE.COM НАСТОЛЬКО УДИВИТЕЛЬНЫЙ, ПОСЕТИТЕ СЕЙЧАС! (Реальные пользователи вашего сайта никогда не увидят этого, только парсеры.)</p>

<a class”search-result-link” href =”http://example.com/”>Посетите сейчас!</a>

</div>

(Более реальные результаты поиска следуют далее)

Это значит, что парсеры, написанные для извлечения данных из HTML на основе классов или идентификаторов, по-прежнему будут работать, но получат поддельные данные или даже рекламу, данные, которые реальные пользователи никогда не увидят, поскольку они скрыты с помощью CSS.

Запутайте парсер: вставьте поддельные, невидимые данные-приманку на свою страницу

Относительно прошлого примера, вы можете добавить невидимые элементы-приманки в ваш HTML-код, чтобы ловить парсеры. Например, такой элемент можно добавить на ранее описанную страницу результатов поиска:

<div class=”search-result” style=”display:none”>

<h3 class=”search-result-title”>Этот результат поиска здесь для предотвращения парсинга</h3>

<p class=”search-result-excerpt”>Если вы человек и видите это, пожалуйста, игнорируйте его. Если вы парсер, нажмите на ссылку ниже 🙂

Обратите внимание, что нажатие на ссылку ниже заблокирует доступ к этому сайту на 24 часа.</p>

<a class”search-result-link” href=”/scrapertrap/scrapertrap.php”>Я парсер!</a>

</div>

(Фактические, реальные результаты поиска следуют далее.)

Парсер, написанный для получения всех результатов поиска, выберет этот результат, как и любые другие реальные результаты поиска на странице, и перейдет по ссылке в поисках нужного контента. Настоящий человек никогда даже не увидит его (из-за того, что он скрыт с помощью CSS) и не пойдет по ссылке. Настоящий и желанный бот, такой как Google или Яндекс, также не будет посещать ссылку, потому что вы запретили это (/scrapertrap/) в своем файле robots.txt (не забывайте об этом!)

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

  • Не забудьте запретить ваш honeypot (/scrapertrap/) в файле robots.txt, чтобы роботы поисковых систем не попадали в него.
  • Для повышения эффективности лучше всего сочетать этот способ с предыдущим советом частого изменения HTML-кода.
  • Постоянно изменяйте ловушки, иначе парсеры научатся избегать их. Измените адрес приманки и текст. Необходимо рассмотреть возможность изменения встроенного CSS, используемого для сокрытия, и использовать вместо этого атрибут ID и внешний CSS, поскольку парсеры научатся избегать всего, что имеет style атрибут с CSS, который используется для сокрытия содержимого. Попробуйте периодически включать-выключать приманку, чтобы парсер выходил из строя не сразу, а через какое-то время.
  • Помните, что злоумышленники могут публиковать что-то наподобие [img]http://yoursite.com/scrapertrap/scrapertrap.php[/img] где-нибудь на форуме (или в другом месте), и, таким образом, обычные пользователи получат отказ в обслуживании, когда они посещают этот форум, а их браузер переходит на ваш адрес приманки. Таким образом, предыдущий совет по изменению URL-адреса важен вдвойне.

“Скармливайте” парсеру поддельные и бесполезные данные

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

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

Не принимать запросы, если User Agent пуст или отсутствует

Часто “лениво” написанные парсеры, не отправляют заголовок User Agent вместе со своим запросом, в отличии от браузеров и сканеров поисковых систем. Если вы получили запрос, в котором отсутствует заголовок User Agent, можно показать капчу или просто заблокировать или ограничить доступ. (Или предоставьте поддельные данные, как описано выше, или что-нибудь еще…)

Подделывать данные — банально, но в качестве меры против плохо написанных парсеров это можно применять.

Не принимайте запросы, если User Agent является обычным парсером; черный список единожды использованного ботами

В некоторых случаях парсеры будут использовать User Agent, который не используется реальными браузерами или поисковиками, например:

  • «Mozilla» (И всё, больше ничего. Я видел несколько вопросов парсинге с такими User Agent. Настоящий браузер никогда не будет указывать только одно слово);
  • «Java 1.7.43_u43» (по умолчанию в HttpUrlConnection Java используется что-то вроде этого);
  • “BIZCO EasyScraping Studio 2.0”;
  • “wget”, “curl”, “libcurl», … (Wget и cURL иногда используются для базового анализа).

Если вы обнаружите, что конкретная строка из User Agent используется парсерами на вашем сайте и не используется реальными браузерами или легитимными пауками, вы можете добавить ее в черный список.

Проверьте заголовки Referer

В дополнение к прошлому совету, ещё можно проверить наличие [Referer] (заголовок https://en.wikipedia.org/wiki/HTTP_referer) (да, это Referer, а не Referrer), так как плохо написанные парсеры могут его не отправлять или всегда отправляйте одно и то же (иногда это “google.com”). Например, если пользователь заходит на страницу статьи со страницы результатов поиска, убедитесь, что заголовок Referer присутствует и указывает на эту страницу результатов поиска.

Остерегайтесь следующего:

  • Реальные браузеры тоже не всегда отправляют его;
  • Referer легко подделать.

Опять же, хорошо подойдет в качестве дополнительной меры против плохо написанных парсеров.

Если браузер не запрашивает ресурсы (CSS, изображения) — это не настоящий браузер

Настоящий браузер (практически всегда) запрашивает и загружает ресурсы, такие как изображения и CSS. HTML-парсеры и сканеры этого делать не будут, поскольку их интересуют только реальные страницы и их содержание.

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

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

Используйте и запрашивайте cookies; это пригодится для отслеживания действий пользователей и парсеров

Вы можете запрашивать cookies для просмотра вашего сайта. Это будет сдерживать неопытных и начинающих разработчиков парсеров, но бот легко может их отправить. Если вы запрашиваете и используете cookies, то с ними вы можете отслеживать действия пользователей и ботов. Таким образом можно применять ограничение скорости, блокировку или отображение капчи для каждого пользователя, а не для каждого IP.

Например: когда пользователь выполняет поиск, установите уникальный идентификационный файл cookies. При просмотре страниц результатов проверьте этот файл cookie. Если пользователь открывает все результаты поиска (это можно узнать из cookies) — это парсер.

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

Обратите внимание, что если вы используете JavaScript для установки и получения cookie, вы заблокируете парсеры, которые не запускают JavaScript, так как они не могут получить и отправить cookies с помощью своего запроса.

Используйте связку JavaScript + Ajax для загрузки контента

Вы можете использовать JavaScript + AJAX для загрузки вашего контента после загрузки самой страницы. Это сделает контент недоступным для анализаторов HTML, которые не поддерживают JavaScript. Довольно часто такой способ является эффективным сдерживающим фактором для начинающих и неопытных программистов, пишущих парсеры.

Необходимо знать:

  • Использование JavaScript для загрузки реального контента снизит удобство использования и производительность
  • Поисковые системы могут не запускать JavaScript, что не позволит им проиндексировать ваш контент. Это может быть неважно для страниц поиска, но имеет значения для страниц со статьями.
  • Программист-автор бота, который знает, что он делает, может обнаружить конечные точки, откуда загружается контент, и воспользоваться ими для обхода мер защиты.

Маскируйте свою разметку, сетевые запросы от скриптов и все остальное

Если для загрузки данных вы используете Ajax и JavaScript, замаскируйте передаваемые данные. Например, вы можете кодировать свои данные на сервере (с помощью чего-то простого, например base64 или более сложного, с несколькими уровнями маскировки, сдвига битов и, возможно, даже шифрования), а затем после получения декодировать и отображать их через Ajax на клиенте. Это будет означать, что кто-то, проверяющий сетевой трафик, не сразу увидит, как работает ваша страница и загружает данные, и кому-то будет сложнее напрямую запросить данные запроса у ваших конечных точек, поскольку им придется перепроектировать ваш алгоритм маскировки данных.

  • Если вы используете Ajax для загрузки данных, вам будет сложно использовать конечные точки без предварительной загрузки страницы, например, требовать некоторый ключ сеанса в качестве параметра, который вы можете встроить в свой JavaScript или HTML.
  • Вы также можете встроить свои закодированные данные непосредственно в исходную HTML-страницу и использовать JavaScript для дешифровки и её отображения, что позволит избежать дополнительных сетевых запросов. Это значительно усложнит извлечение данных с помощью парсера, заточенного под HTML, который не запускает JavaScript. Разработчик парсера должен будет реконструировать ваш JavaScript (который вы также должны закодировать).
  • Отличным ходом будет менять способы маскировки, чтобы сломать парсеры, которые её раскрыли.

И все-таки у этого способа есть несколько недостатков:

  • На практике это бывает довольно сложно реализовывать, поддерживать и отлаживать.
  • Это будет неэффективно против парсеров и сканеров, которые запускают JavaScript, а затем извлекают данные. (Большинство простых HTML-парсеров не поддерживают JavaScript)
  • Это сделает ваш сайт нефункциональным для реальных пользователей, если у них отключен JavaScript.
  • Пострадает производительность и время загрузки страницы.

Нетехнические способы борьбы:

Ваш хостинг-провайдер может предоставлять защиту от ботов и парсеров

Например, популярный CloudFlare обеспечивает защиту от ботов и взлома, которую вам просто нужно включить, как и AWS. Существует также mod_evasive, модуль для Apache, который позволяет легко реализовать ограничение скорости.

Попросите людей не парсить ваши данные, и некоторые будут уважать ваше желание

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

Найти адвоката 🙂

Они знают, как бороться с нарушением авторских прав, и могут отправить письмо о прекращении и отказе от них. Также в этом отношении помогает DMCA. Такой подход используют Stack Overflow и Stack Exchange (это в основном рекомендация для США).

Сделайте ваши данные открытыми, предоставьте API

Это может показаться контрпродуктивным, но вы могли бы сделать ваши данные открытыми и требовать указания авторства и ссылки на ваш сайт. Может быть, даже получать за это реальную плату… Опять же, Stack Exchange предоставляет API, но с указанием авторства.

Прочие способы:

  • Найдите баланс между удобством использования для реальных пользователей и устойчивостью к ботам: все, что вы делаете, так или иначе негативно повлияет на работу реальных пользователей, поэтому вам нужно будет искать компромисс.
  • Не забывайте про свой мобильный сайт и приложения: если у вас есть мобильная версия вашего сайта, будьте осторожны, боты тоже могут её парсить. Если у вас есть мобильное приложение, оно также может попасть под атаку парсеров. Можно проверить сетевой трафик, чтобы определить конечные точки REST, которые он использует.
  • Если вы используете специальную версию вашего сайта для конкретных браузеров, например, урезанную версию для более старых версий Internet Explorer, не забывайте, что боты тоже могут её видеть и сканировать.
  • Комбинируйте эти советы, и выберите то, что для вас работает лучше.
  • Парсеры могут сканировать другие парсеры: если существует один веб-сайт, на котором отображается содержимое, взятое с вашего сайта, другие парсеры могут взять его с сайта этого парсера.

Какой самый эффективный способ защиты от парсинга?

Из нашего опыта написания парсеров и помощи людям в написании парсеров, наиболее эффективными методами являются:

  • Частое изменение разметки HTML
  • Ловушки и поддельные данные
  • Использование замаскированного JavaScript, AJAX и файлов cookie
  • Ограничение скорости при обнаружении парсера и последующая блокировка.

Читайте также:

  • Статья на Википедии о веб-парсинге. Множество подробностей об используемых технологиях и различных типах веб-парсинга, общая информация о том, как делается веб-парсинг, и его законность.

Удачи в опасном путешествии по защите вашего контента!..

0
50 комментариев
Написать комментарий...
Зеленый и громкий

Спасибо за советы, доработал свой парсер чтобы он не палился!

Ответить
Развернуть ветку
Anton Vukolov

"Чтобы противостоять парсингу (также известному так же как веб-парсинг, веб-анализ данных, веб-сканер или извлечение веб-данных), необходимо понять, как работают парсеры"

Ответить
Развернуть ветку
GR

Опасно увлекаться защитой путем скармливания парсеру текста, который отличается от того, что видит пользователь.

За это можно получить бан от поисковых систем, они могут посчитать это обманом пользователя.

Т.е. если поисковый бот (парсеры часто под них маскируются) и пользователь видят на странице разное, то поисковик не может достоверно понять, какой текст будет показан реальному пользователю и пессимизирует сайт в выдаче.

Ответить
Развернуть ветку
Леонид Николаевич

Григорий, спасибо за важное замечание!

Ответить
Развернуть ветку
Максим Кульгин
Автор

Вы абсолютно правы, но через revers dns lookup можно проверить кто заходит парсер или поисковый бот. 

Ответить
Развернуть ветку
Gene Semerenko

Единственный способ названный эффективным - изменение разметки.
Но это поможет только против "любителей".
Большинство других способов защиты поможет Вам словить нехилые пенальти от гугла (за клоакинг например). В общем проще сразу закрыть всё паролем и в интернет не ходить. :)

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Максим Кульгин
Автор

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

Ответить
Развернуть ветку
Зеленый и громкий

Громкое заявление!

Ответить
Развернуть ветку
В.М.

Я думаю если копирайт добавить на фотку то это уже не хило защитит рядовой магазин) придется ведь или каждую фотку потом замазывать и к каждому товару перезагружать, а это не реально если позиций несколько тысяч

Ответить
Развернуть ветку
Николай Лискин

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

Ответить
Развернуть ветку
В.М.

По моему здесь не выглядит копирайт лишним, зато защищает

Ответить
Развернуть ветку
Александр Батищев

Такой копирайт обрезать легко, но вручную конечно муторно все

Ответить
Развернуть ветку
Николай Лискин

С помощью GIMP легко можно создать пакетный обработчик фотографий который удалит данный копирайт либо наложит поверх новый, тем самым замазав Ваш. ContentDownloader складывает фото в папку, GIMP обрабатывает пачкой данную директорию, на выходе фото без или с новым лого. А вообще и вручную тем же GIMP при нужных знаниях можно удалять такие копирайты тратя не более 1 минуты на изображение

Ответить
Развернуть ветку
Максим Кульгин
Автор

Фотки редко берут. Но да конечно поможет. 

Ответить
Развернуть ветку
Ринат Г.

Большинство легко срезать с помощью opencv

Ответить
Развернуть ветку
Bulat Ziganshin

tldr: вам платят за то что вы избавляетесь от своих же конкурентов. о дивный новый бизнес!

Ответить
Развернуть ветку
Максим Кульгин
Автор

Звучит немного странно но да. Хотя обычно просто просят дружеского  совета - а не платной консультации. 

Ответить
Развернуть ветку
Bulat Ziganshin

отвечайте что другие деволы не будут вас уважать если вы дадите такую консультацию бесплатно

Ответить
Развернуть ветку
Александр Антонов

https://habr.com/ru/company/globalsign/blog/466911/

В США есть прецедент запрета на препятствие парсинга, и я думаю это правильно

Ответить
Развернуть ветку
Леонид Николаевич

1. Применительно к вышеприведённому решению американского суда, предметом которого является парсинг персональных данных из общедоступных профилей пользователей LinkedIn, в России персональные данные даже, если они размещены в социальных сетях: ВКонтакте, Одноклассники, МойМир, Instragram, Twitter, а также на интернет-порталах Авито и Авто.ру, НЕ являются общедоступными, потому что:

1) их размещение в социальных сетях НЕ делает их автоматически общедоступными;

2)  без письменного согласия субъекта персональных данных не представляется возможным утверждать, что они предоставлены именно указанным субъектом;

3) социальные сети не являются источником общедоступных персональных данных применительно к положению статьи 8 Федерального закона от 27.07.2006 №152-ФЗ "О персональных данных", которой введено определение общедоступных источников персональных данных, согласно которой, в целях информационного обеспечения могут создаваться общедоступные источники персональных данных (в том числе справочники, адресные книги), в общедоступные источники персональных данных с ПИСЬМЕННОГО СОГЛАСИЯ субъекта персональных данных могут включаться его фамилия, имя, отчество, год
и место рождения, адрес, абонентский номер, сведения о профессии и иные персональные данные, сообщаемые субъектом персональных данных;

4) по условиям пользовательского соглашения соцсетей и Интернет-порталов  владелец персональных данных даёт согласие только на доступ к информации, которую он размещает на своей странице, но не на их обработку третьими лицами. 

2. Такое решение принял Арбитражный суд города Москвы 5 мая 2017 года по делу № А40-5250/17-144-51 по заявлению АО «Национальное Бюро Кредитных Историй» об обжаловании предписания Роскомнадзора № П-77/07/524-нд/1/230 от 26.08.2016 на основании  выявленного им нарушения в части соответствия деятельности по обработке персональных данных требованиям законодательства по результатам его плановой выездной проверки, потому что отсутствовало письменное согласие субъектов содержащихся в  открытых источниках – в вышеуказанных социальных сетях и интернет-порталах персональных данных на их обработку,.

2.1. Суд апелляционной инстанции согласился с выводами нижестоящего суда (постановление Девятого арбитражного апелляционного суда от 27 июля 2017 года по делу № А40-5250/17).

2.2. Суд кассационной инстанции и Верховный Суд РФ встали на сторону Роскомнадзора и не нашли оснований для отмены обжалуемых судебных актов. (постановление Арбитражного суда Московского округа от 9 ноября 2017 года по делу № А40-5250/2017, Определение ВС РФ от 29 января 2018 года по делу № 305-КГ17-21291). 

Ответить
Развернуть ветку
Максим Кульгин
Автор

Мы не парсим персональные данные, т.к. это действительно может быть запрещено законом (их обработка). 

Ответить
Развернуть ветку
Леонид Николаевич

Интересные в США законы, если суд толкует, что "закон о компьютерном мошенничестве и злоупотреблениях не применяется к информации, доступной для широкой общественности."!

Не удивлюсь, если в США, а потом в России появится аналогичный судебный прецедент в отношении защиты сайтов от DDos-атак!

 Теперь парсеры сайтов в Рунете возьмут эти доводы и аргументы на заметку, тем более, в России, оказывается такие прецеденты в отношении парсинга уже были!

Ответить
Развернуть ветку
Расул Юсупов

Статья от студентов но не от парсеров))

Ответить
Развернуть ветку
Kozinov

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

Ответить
Развернуть ветку
Максим Кульгин
Автор

Дело в том, что нельзя запретить то, что разрешено законом - а именно сбор общедоступной информации. Иными словами, название товара, цена, артикул ит.п. - это фактические данные, которые каждый может скачать в любом виде даже с помощью условно автоматических средств типа расширений для Хрома. Мы делаем тоже самое... Поэтому в соглашении может быть написано что угодно, законной силы это не должно иметь (советы наших юристов, не мое мнение). Вы же можете написать, что каждый "вошедший должен нам почку :)". И что ? :)

Ответить
Развернуть ветку
Вера Гагарина

Защищай не защищай - кому надо спиздеть — тот спиздит!

Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку

Комментарий удален модератором

Развернуть ветку

Комментарий удален модератором

Развернуть ветку
Risent Veber

Строго говоря - никак. Hеобходимо закрыть доступ к сайту для обычных пользователей - это единственный 100% вариант.

Ответить
Развернуть ветку
Максим Кульгин
Автор

отчасти да, но в действительности есть сайты, которые ТАК сложно парсить, что лучше даже не начинать. 

Ответить
Развернуть ветку
Risent Veber

Например auto.ru c защитой от https://variti.com/

Ответить
Развернуть ветку
Максим Кульгин
Автор

парсим их. Но да, защита не плохая.

Ответить
Развернуть ветку
Risent Veber

а так для большинства сайтов Random-UA+Cookie storage+IP from Srapper net будет достаточно, для особо сложных видимо grid headless браузеров нужно держать + ограничивать кол-во действий в каждом из них в момент времени, а также random time fluctuation между ними.

Ответить
Развернуть ветку
Anton Vukolov

Пользуясь случаем, хочу сказать, что у вас слабоватые сейлзы - один раз созвонились, скинули пример выгрузки и пропали 🤷‍♂️

Ответить
Развернуть ветку
Максим Кульгин
Автор

Спасибо есть над чем поработать

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Максим Кульгин
Автор

Да ок

Ответить
Развернуть ветку
Mr VAUS

Godno

Ответить
Развернуть ветку
Леонид Николаевич

После прочтения этой статьи сильно поубавилось желание создавать свой профессиональный сайт!!! Тем более, после альтернативного предложения публичного предоставления API-адреса сайта, что категорически не рекомендуется для предотвращения DDos-атак, потому что именно его сокрытие значительно помогает в эффективной защите от них.

Ответить
Развернуть ветку
Aleks Zotov

В смысле? API же к реплике прикручивают и выдают доступ по ключу, таким образом, наоборот, увеличивая доступность сервиса для обычных пользователей.

Ответить
Развернуть ветку
Леонид Николаевич

 Для защиты сайта от DDos-атак необходимо скрывать IP-адрес сервера, на котором размещён сайт, потому что, если хакеры не могут определить мишень, им нечего атаковать!

Ответить
Развернуть ветку
Максим Кульгин
Автор

гм. а доменное имя куда ссылаться будет?

Ответить
Развернуть ветку
Леонид Николаевич

Во всяком случае так работает сервис защиты от DDoS-атак Deflect. https://clck.ru/JXnUu

Ответить
Развернуть ветку
Сергей Багрецов

*требуйте создания учетной записи.*

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

Такие магазины призваны не запускаться и не иметь права получать дешёвых клиентов.

Ответить
Развернуть ветку
Максим Кульгин
Автор

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

Ответить
Развернуть ветку
Whoer Net

https://whoer.net/ru/vpn скидки на впн, ру сервера

Ответить
Развернуть ветку
Pavel Rikovsky

А как на счет auto.youla.ru, там полно кук ... 

Ответить
Развернуть ветку
Станислав Кодрашов

Динамическа обфускация
+ парсить будет очень тяжело
- у пользователей будет заметно больше нагрузка на устройство(кода станет в разы больше)
-это сложный процесс, потребует много обновлений во всей ИТ системе

Написать регулярки, цсс селекторы и хпути для парсинга такого сайта будет нереально
Все посетители сайта каждый раз получают новый код сайта, но сайт выглядит как надо.
(останется только визуальное распознавание сайта, а его хакеры не любят)

В разной степени этим пользуются такие сайты как гугл, твиттер, фейсбук и т п
Это спец программы, что берут верстку или код вашего сайта и домешивают в него не рабочего бессмысленного кода и элементов, при этом переделывая(переписывают) ваш код в другой но работающий как оригинал.

Что дает в итоге абсолютно не читаемый код который нереально понять, если настоящая логика сложная, а уровень обфускации высокий, то чтоб понять как работает "изуродованный" понадобится разбирать его неделями. А он меняться у нас будет раз в 3 дня или каждый раз при загрузке страницы)) 

Каждый раз новые классы, новые ИД, лишние прослойки и обертки и клоны кнопок/картинок/форм расположенные в разных местах на разных слоях оберток.

Если открыть страницу сайта и сохранить ее код, а потом обновить страницу и сравнить код, то он будет абсолютно разным и будет выглядеть так если кто-то упал лицом на клавиатуру. 
+можно будет шутить и делать код вашего сайта в виде рисунка из букв с посланиями для хакеров)  

Ответить
Развернуть ветку
Mihail Arhipov

На мой взгляд, а парсеры я пишу уже много лет, надо брать один или несколько способов, и доводить его до совершенства, а не все сразу.
Потому что какието минимальные защиты парсеры могут обходить на автомате. А вот если эта защита доведена до ума, то представляет реальную проблему.
Те же самые динамические теги, мне понравилось как месяц назад их поменял Гугл, реально очень сложно зацепиться за нужный тег, потому что там меняется буквально все, и раз в неделю. А в 99% процентов сайтов они обходятся простым XPATH выражением. Хотя их реально сделать так, что любой парсер повесится.
Из самых эффективных способов защиты от парсинга, он тут кстати не упомянут, на мой взгляд это отслеживание как именно осуществляется переход со страницы на страницу. Достаточно на странице каталога вставить скрипт, запоминающий куда шелкнул пользователь для перехода, а на странице товара проверить :) И это отсечет подавляющее количество парсеров, потому что они не кликают мышкой, а пользователи кликают :)
Если сайты будут хорошо защищены, то это поднимет требования для программистов и их уровень оплаты, что я тоже приветствую
Хорошая статья.

Ответить
Развернуть ветку
Игорь Рябушкин

стратегия такая: контент должен представлять собой непрерывный (хотя можно и дискретный) информационный поток. тогда все до конца скачать будет затруднительно.

и второе - это все таки авторизованный доступ. Никому не давать видеть все. каждому свое.

и проблемы нет.

Ответить
Развернуть ветку
Игорь Рябушкин

стратегия такая:

контент должен представлять собой непрерывный (хотя можно и дискретный) информационный поток. тогда все до конца скачать будет затруднительно.

и второе - это все таки авторизованный доступ. Никому не давать видеть все. каждому свое.

давать веб-апи, внешняя интеграция залог успеха. чтобы не парсили, а брали прилично, но по токену. еще лучше за адекватную плату.

и проблемы нет.

Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку
47 комментариев
Раскрывать всегда