• Как организовать защиту от парсинга сайта?

    @starosta6123
    1. Сайт изначально предназначен для публикации, то есть он открыт.
    2. Если вы не хотите чтобы информация была открыта, не публикуйте.

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

    Бросьте это занятие!

    Не существует защиты созданной человеком, которую не возможно сломать, вопрос времени...
    Единственный путь, это шифрование с выдачей ключа клиенту. Но клиент - человек не надежен, и информация уплывет, вопрос цены!

    И еще раз бросьте это!

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

    Последний совет: бросьте это!

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

    А если хотите поиграться, то пришла в голову идея: перемешивание по определенному алгоритму текста, который потом восстанавливается, применение стилей для скрытия "фальшивых" слов или фраз. Например, задать стиль, который скрывает каждое второе предложение или слово. Но к сожалению, это ломается на ура! Но доставит радости для взломщиков :-)

    Извините, за столь большой сумбур!

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

    2. Верстка. Не знаю про бан от поисковиков, но это тоже ломается. Просто убираете теги и все. Просто в парсер добавляется "умный" фильтр. Можно конечно где-то картинку заменить фоном, или часть текста картинкой, но и на это можно сделать разборщик.

    3. Блокировка по IP не прокатит, так как могут пострадать реальные люди, достаточно применять динамический IP.

    А вообще, если хотите спастись от простых парсеров, то комплекс мер может помочь. Так же могу натолкнуть на идею, того, что парсеры обычно очень активны, и по количеству запросов с одного IP, по USER_AGENT, и другим меткам, а так же по отсутствию javascript, по обработке тега <МЕТА> redirekt.info/article/redirekt-na-html-s-zaderzhko... (отложенный редирект) и другим признакам. Можно запихнуть скрытую картинку (style="display: none"), большинство парсеров ее могут дернуть (зависит от настроек).

    В общем, можно поставить задачу в другом ключе: "Расстановка ловушек для парсеров". То есть ловить на том, чего обычные люди и браузеры делать не будут. Например, заполнять "скрытое поле пароль". Удачные ловушки дадут вам возможность выявить подставных, но лучше делать несколько проверок, а то можно и реального пользователя забанить. А я бы не стал банить, а сливал бы немного или частично измененную инфу. Эта инфа может стать маркером для выявления того, кто действительно желает с вас "слить".

    Все, удачи!
    Ответ написан
    4 комментария
  • На чем писать парсер сайтов? на PHP или Ruby?

    butteff
    @butteff
    Раз в тысячу лет заправляю свитер в носки
    Вообще php, тем более многопоточно, будет очень долго работать.
    Я бы писал это вообще под десктоп на чем-то, а не на пыхе.
    Но на всякий случай вброшу ссылку, существенно облегчающую жизнь
    simplehtmldom.sourceforge.net
    Ответ написан
    1 комментарий
  • Как эффективнее всего изучать yii2?

    @vkdv
    Прости что лезу не в свое дело, но мое мнение, что yii2 лучше вообще не изучать. Изучай Laravel/Symphony etc

    Приведу несколько аргументов (в сравнении с laravel):

    1) Yii2 довольно слабо следует принципам SOLID и более того, не предоставляет в достаточной мере архитектурного решения разработчику, чтобы он сам им следовал
    2) Yii2 Костылен, а его исходники мягко говоря не очень. Например behaviors (костыль) против middlware(прозрачное решение)
    3) Yii2 Имеет устаревшие сервисы из коробки относительно Laravel , который развивается куда более активно.
    Помимо прочего в Laravel намного больше готовых сервисов (Elixir , scheduling, Queue , Blade, Storage, Broadcast , Notifications) Вместо этого в yii2 есть только bower assets - который представляет с собой дикий костыль и откровенно ужасен, да еще и не безопасен, а также вроде в yii2 есть сервис для работы с файловой системой, но я с ним не работал. Остальные сервисы типа bootstrap , console etc есть и там и там
    4) Магия Yii2 не способствует контролю за кодом и прозрачности
    5) Yii2 имеет довольно плохо продуманную архитектуру, о чем говорит например тот факт, что jquery вшит в ядро фреймворка (возможно и некоторые другие ассеты) и это очень странно. Особенно когда тебе нужно запускать консольные приложения
    6) ActiveRecord в yii2 доволбно запутан, по сравнению с https://laravel.com/docs/5.3/queries (кончено это субъективно)
    7) Yii2 не особо популярен в мире, у него плохая документация и я думаю он серьезно отстоет от конкурентов.

    Есть конечно у него и плюсы, например он быстрее laravel и у него есть поддержка модулей(что решается в laravel подключением пакета)
    Ответ написан
    9 комментариев
  • Свой шаблонизатор на php?

    index0h
    @index0h
    PHP, Golang. https://github.com/index0h
    Осиль twig, или smarty, лучше все равно не напишешь.

    Например требуется вывод всех групп из таблицы БД в цикле foreach.

    Шаблон работает с БД на прямую? Меняй драг диллера))
    Ответ написан
    Комментировать
  • В чем смысл ВУЗа?

    @Anthony7
    Лохотрон это, просто попробуй связаться с работодателями с интересной для тебя вакансией, скажи что знаешь все что они хотят, но диплома у тебя нет. Если согласятся, забивай на ВУЗ. В наших вузах из полезного только столовая и телки. Я лично отучился и толку никакого, последние пару лет тролил преподов, что они тупее большинства студентов (мой ВУЗ сейчас в середине рейтинга лучших универов по стране). Они растягивают любую программу и добавляют туда воды, чтобы ты подольше платил)
    Ответ написан
    3 комментария
  • Стоит ли использовать ооп?

    index0h
    @index0h
    PHP, Golang. https://github.com/index0h
    То, что легче без ооп - безусловно, для скрипта на 100 строк, это будет лишним.

    В остальном - однозначно нужно.
    ООП дает вам понятие "сущностей данных", как минимум. Можно конечно обмазываться массивами, но в этом случае лучше не используйте в лексиконе слово "безопасность".
    ООП дает разграничение обязанностей. Можно конечно нагородить 1кк функций и сварганить на их основе вермишельку, когда выльете пару ведер крови из глаз - вспомните мои слова.
    ООП дает заменяемость кода по интерфейсу (Полиморфизм), как следствие - возможность варьировать логику, без миллиона switch-case и сложных условий.
    ООП дает сокрытие данных (Инкапсуляция). Если переменную можно изменить в любом месте проекта (глобальную например) - она будет где-то изменена, вы об этом можете не узнать (или попросту забыть), как следствие ваш код будет работать не предсказуемо.
    ООП дает возможность расширять функционал порождаемых сущностей (Наследование), как следствие - DRY.

    То, что Виталий Пухов написал не верно. Легко !== правильно, удобно, человеко-понятно, тестируемо, надежно. Легко как правило писать говно. Фраза "работает же" как правило значит: "да, я понимаю, что оно хреновое, но лучше не могу".

    И писал пару робот на нём сильной разницы в скорости между ооп и не ооп проэктами не замечал.

    Вы не туда смотрите)). Производительность на stateless языке... В общем посмотрите на компилируемые))

    * Про vk вы правильно сказали, но забыли 2 важных нюанса: он писался, когда ООП в php особо не было; у них свой KPHP))
    * Для сравнения у facebook тоже свой php: hhvm, но он очень даже объектный.
    Ответ написан
    1 комментарий