Защита сайта на php от парсинга без ущерба для поисковиков?

Question

[Роман Левкович]

Добрый день,

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

Рассматриваем варианты:
Ограничение частоты запросов и объемов загружаемых данных
Использование CAPTCHA

Но боимся, что пострадает индексация.
Что посоветуете?

Answer 1

[Робот]

Это нереально ))

Comments

[Роман Левкович]

многообещающий ответ )

Answer 2

[Dmitry Bay]

Есть только один достойный способ защититься от парсеров - не показывать никому ничего!

по факту, варианты реализации и способы обойти:
1) капчи - правильно отметили, капча стоит 10копеек за штуку. дешево.
2) паузы в выдаче - боты могут попадать на такую штуку, а парсеры просто используют прокси. Причем, у вас очень большая база? я бы прошелся просто с паузами раз в 10 секунд, что дает 6 страниц в минуту и 360 в час.
3) банить по ип? и снова прокси решают.
4) возможно закрывать доступ для неавторизированных пользователей. Но потеряете индексацию.

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

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

Comments

[Роман Левкович]

база около 1 млн страниц. Видимо без шансов и с поисковиками дружить и инфу защищать )

[Dmitry Bay]

Роман Левкович: кстати, вопрос на засыпку - база юр лиц случайно не с 2гис?)

Answer 3

[Dimonchik]

разрабатывайте юридические методы защиты,

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

Answer 4

[Pretor DH]

Защищатся нужно на уровне дизайна приложения на стороне клиента, а не сервера.

НАПРИМЕР: Создавать страницу каждого клиента без структурных данных, просто общую с названием клиента и пачкой рекламных зазывалочек. Данные получать AJAX-ом после явного клика на кнопку/изображение (но не тег A). А адрес динамически генерировать js-том на основе например перекодированого одноразового-тикета, id клиента и id информации (но не php-генерируемый). Никаких явных ссылок на странице или в коде js!!!

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

Думаю вам такого достаточно. Індексироваться така страница будет на уровне названий фирм. А спарсить по простому автоматом не смогут - нужно будет написать специальный скрипт.

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

Но!
!!!СЕРЕБРЯНОЙ ПУЛИ НЕТ!!!
Нужно строить многофакторную защиту. Если все зделать с достаточным уровнем сложности, быдлокодер не сможет обойти. А профессиональный уважающий себя програмист не станет таким заниматься.

Comments

[Сергей delphinpro]

Кому нужна инфа - не поленится написать специальный скрипт. тем более я лично ничего сложного в описании вашей "защиты" не увидел. Единственное препятствие - генереруемый урл. Ну так алгоритм генерации доступен в js файле, данные (все id, тикеты и прочее) получаем запросом - всё есть для генерации адреса.
Про ограничение времени там выше написали - решается прокси-листом.
В общем скриптик написать пару часов-день-два, в зависимости от уровня программиста.

Как видите, этого сосем не достаточно :)

[Макс]

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

[Pretor DH]

Макс: Можно на картике нарисовать круг каждый раз в новом месте, и сверять на сервере координаты клика. Можно в локалсторадже записать фигню каккую-то (каждый раз другую) на стади загрузки неполной страницы, и нужно будет как минимум 3 запроса делать для того чтобы. Вопрос в сложности и количестве проверяемых параметров. Я же сказал "ДОСТАТОЧНО" - от юзера. А от програмиста не спасет ни каптча, ни блокировка ИП. === Для таких систем строятся комплексные системы с многоуровневой защитой. Но и они обходятся было бы желание и/или зыск и время.

Answer 5

[Дмитрий Энтелис]

Если есть некий контент, на котором планируется зарабатывать, решение - прятать его под замок после оплаты.
Оплату брать либо за доступ к каждой единице контента, либо если абонемент - с ограничением на количество контента в период времени (что бы условно купив 10-15-20 учеток Вас не просканили)
Пример такой реализации www.nesprosta.ru/?type=show_home&id=65810 (первая ссылка которая пришла в голову)

Если непосредственно зарабатывать на контенте желания нет, то любые попытки защититься от парсинга априори обречены на неудачу. Любой контент который Вы отдаете поисковику остается в его кеше. Даже если Вы воткнете лимиты на доступ к сайту(что само по себе проблемно - прокси бесплатных существует великое множество, не говоря про возможность в любой момент поднять сотню-другую на амазоне) - любой желающий Вас спарсить всегда может парсить не Вас напрямую, а кеш поисковика ( webcache.googleusercontent.com/search?q=cache:YMI-... )

Answer 6

[mirosas]

Это зависит от дух параметров:

1. насколько вам важно чтобы у вас не спарсили информацию.
2. насколько тем кто прет у вас информацию она нужна.

Если 2 больше 1 то вы проиграли.

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

С поисковыми роботами отдельная проблема. да. У них как правило фиксированные ip адреса - по ним их можно и вычислять.

Ограничение частоты запросов и объемов загружаемых данных
- прокси решают эту проблему.

Использование CAPTCHA
- обычных пользователей замучаете капчей. Если я не ошибаюсь разгадывание капч стоит около 10 копеек за одну капчу.

В целом предлагаемые вами методы помогают защитить данные от парсинга стоимостью до 150 долларов.

Comments

[romy4]

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

[mirosas]

romy4: вроде такое было только у Яндекса, и только с 07 по примерно 09 год. Когда их спамеры на лопатки положили. Сейчас вроде у всех поисковиков дела получше с борьбой со спамом и они обходятся другими - более надежными алгоритмами. Да даже если говорить о Яндексе 07-го года, то его робот по поиску расхождений в целом неплохо маскировался под обычного юзера и не был бы отловлен системой как парсинг-робот, как итог получил бы тот же контент что обычный юзер.