User-Agent и идентификация. Взгляд с разных сторон

Думаю, что все, кто занимается программированием для web, знают, что такое User-Agent и с чем его едят. Я решила немного обобщить знания и собрать их в одной статье. Сначала определение (Википедия в помощь).

User Agent — это клиентское приложение, использующее определённый сетевой протокол. Термин обычно используется для приложений, осуществляющих доступ к веб-сайтам, таким как браузеры, поисковые роботы (и другие «пауки»), мобильные телефоны и другие устройства.
При посещении веб-сайта клиентское приложение обычно посылает веб-серверу информацию о себе. Это текстовая строка, являющаяся частью HTTP запроса, начинающаяся с User-agent: или User-Agent:, и обычно включающая такую информацию, как название и версию приложения, операционную систему компьютера и язык. У «пауков» эта строка часто содержит URL и email-адрес, по которым веб-мастер может связаться с оператором «паука».

User-Agent и вебмастер

Что дает вебмастеру и оптимизатору знание о таком понятии как User-Agent? Если знать названия поисковых роботов (и роботов различных ресурсов, краулеров и т.д.), то можно самостоятельно регламентировать доступ этих роботов к различным частям сайта. Это делается в небезызвестном файле robots.txt, который должен находиться в корневой папке сайта.

Вот как описан механизм работы робота Яндекса в зависимости от настроек в robots.txt (полная версия мануала по использованию robots.txt):

В роботе Яндекса используется сессионный принцип работы, на каждую сессию формируется определенный пул страниц, которые планирует закачать робот. Сессия начинается с закачки robots.txt сайта, если его нет, он не текстовый или на запрос робота возвращается HTTP-код отличный от '200', считается, что доступ роботу не ограничен. В самом robots.txt проверяется наличие записей, начинающихся с 'User-agent:', в них ищутся подстроки 'Yandex', либо '*' (регистр значения не имеет), причем, если обнаружено 'User-agent: Yandex', директивы для 'User-agent: *' не учитываются. Если записи 'User-agent: Yandex' и 'User-agent: *' отсутствуют, считается, что доступ роботу не ограничен.

Итак, для "управления" зоной видимости определенного робота надо добавить в robots.txt несколько строк. "Распознаются" директивы Allow и Disallow, соответственно разрешающие и запрещающие доступ роботу/краулеру/и т.д. к определенным частям вашего ресурса.

Списки названий роботов поисковиков открыты, их можно без проблем найти в интернете. Вот, например, совсем недавно, буквально месяц назад (6 мая 2010 года), на блоге Яндеска был опубликован свеженький список User-Agent-ов его роботов.

Итак, вы можете редактировать robots.txt, чтобы запретить или разрешить доступ определенных роботов к разным частям сайта. Рассмотрим конкретный случай: у Гугля есть новостной робот, но архивы вашего сайта не нуждаются в полном обходе этим роботом, поэтому пишем:

User-agent: Googlebot-News
Disallow: /archives

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

User-agent: Googlebot
Disallow: /

User-agent: Googlebot-News
Disallow:

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

Помимо роботов поисковых систем по сети шарят множество всяких краулеров, собирающих контент для разных нужд. В буржунете их наблюдается больше, по крайней мере больше жалоб :) Краулеры могут поднимать нагрузки на ваш сервак на нежелательный уровень. А "палятся" некоторые из них, как вы уже, наверное, догадались, своими User-Agent-ами. В буржунете я не раз встречала целые списки юзерагентов для блокировки, выложенные в паблик. При желании вы можете их найти. Например: The top 10 spam bot user agents you MUST block. NOW. ("Десять User-agent-ов спам-ботов, которые вы ДОЛЖНЫ заблокировать. НЕМЕДЛЕННО.") Или, как вариант, можете посмотреть сайт Bots vs Browsers, на котором в момент написания статьи собрана информация о 499551 юзерагентах, из которых ботов - 4439. Или уже известный многим сайт www.user-agents.org.



Информацию о юзерагентах ваших "посетителей" вы можете посмотреть в лог-файле статистики. Если увидите что-нибудь подозрительное — уже знаете, как поступить :)

Отмечу также, что для каждого движка есть отдельные наборы рекомендаций к правилам составления robots.txt для роботов поисковых систем. Прежде чем самостоятельно придумывать конфигурацию, поищите в Интернете.

User-Agent и программист парсеров :)

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

Итак, рассмотрю вопрос применения знаний о User-Agent-ах со стороны создателя парсеров. Все более-менее серьезные библиотеки работы с HTTP поддерживают возможность подстановки в заголовки формируемых запросов "левой" информации о браузере. Не забудьте поменять установленные по умолчанию значения на что-нибудь более правдоподобное. (Отсутствие информации о браузере подозрительно в первую очередь). У Indy, например, по умолчанию стоит

Mozilla/3.0 (compatible; Indy Library)

Ну как тут не спалиться? Это первый претендент на добавление в black-list.

libwww, lwp-trivial, curl, PHP/, urllib, GT::WWW, Snoopy, MFC_Tear_Sample, HTTP::Lite, PHPCrawl, URI::Fetch, Zend_Http_Client, http client, PECL::HTTP — все это может вас выдать с головой.

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

Чтобы быть в курсе обновлений блога, можно подписаться на RSS.

RSSAdder — добавление RSS в список RSS-агрегаторов

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

Интерфейс программы сейчас выглядит следующим образом:


Все настройки хранятся в INI-файле: это и информация об RSS (если вы ее сохраните), и список RSS-агрегаторов. Список агрегаторов хранится в следующем виде:

[SITExx]
url=
field_url=
field_rss_url=
field_rss_name=
field_dsc=
field_keys=
field_email=
key_delimiter=

[SITExx] - RSS-агрегатор, где xx - номер по порядку
url - ссылка на страницу добавления RSS-ленты
field_url - поле "URL сайта"
field_rss_url - поле "URL RSS"
field_rss_name - поле "Название RSS/сайта"
field_dsc - поле "Описание сайта"
field_keys - поле "Ключевые слова"
field_email - поле "Email"
key_delimiter - разделитель ключевых слов

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

Сначала введите в шапке формы данные о своей RSS-ленте и о блоге.

Чтобы добавить RSS в каталог из списка, расположенного в левой части формы, надо дважды кликнуть на нужном элементе списка. В WebBrowser загрузится форма, в которой будут заполнены поля в соответствии с данными в шапке и данными о названиях/id полей в ini. Вам остается только довводить недостающие параметры (рубрики, капчу и т.д.) и нажать сабмит. Если регистрация в каталоге состоит из нескольких шагов, то после заполнения всех полей вам придется самостоятельно перейти к следующему шагу. Если на следующем шаге от вас требуется заполнение полей, предусмотренных в настройках, то вы можете просто нажать форму "Заполнить форму".

Еще из нововведений:
- рядом с каждым полем сделала кнопочку "Копировать в буфер", на всякий случай :)
- если вы редактируете список агрегаторов в INI-файле, то после его сохранения можно обновить данные в списке не закрывая программу, а просто нажав на "Обновить список из INI"
- добавила закладку HTML Form Viewer для удобства исследования новых RSS-каталогов. Если вы нашли новый каталог, то введите URL для добавления ресурса в строку в верхней части формы, нажмите "Загрузить". После этого загрузится форма, а внутри каждого инпута типа "text" и "textarea" будут подписаны их name и id.



Вам останется только впечатать эти названия в форму в нижней части и нажать "Сформировать код". И в memo появится запись, для добавления в INI-файл, составленная по шаблону. Не забудьте изменить "xx" в строке "[SITExx]" на номер по порядку в соответствии с ранее добавленными записями, а потом дописать полученный результат в свой INI-файл.

У меня к вам есть просьба. Я включила в INI-файл 51 RSS-агрегатор — это мой посильный вклад в формирование списка. Сейчас — ваша очередь. присылайте настройки для новых каталогов на емейл momkarla@gmail.com или оставляйте в комментах. Я буду собирать и выкладывать обновленный список у себя на блоге.

Скачать RSSAdder (1.1 Mb) (в комплектации — 51 RSS-агрегатор).
Редакция от 24.08.2010: Скачать последнюю версию INI-файла (82 агрегатора). На случай, если кто-то скачивал более раннюю версию программы и нужен только "свеженький" конфиг. После скачивания замените INI-файл в папке с программой, оставив свои данные о блоге.

У кого проблемы с Яндексом :) — качайте RSSAdder с зеркала.

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

P.S.: У кого есть аккаунт на Sloger.net — проголосуйте, пожалуйста, за новость.
___

Отдельное спасибо за размещение ссылки на этот пост:
автору блога "Заметки молодого блоггера"
___

Чтобы быть в курсе обновлений блога, можно подписаться на RSS.

Парсинг форумов

Немного отвлекусь от темы автоматизации постинга в дневники и поговорю о парсинге форумов. Все-таки тема дневника — это парсинг. А форумы представляют собой широченное поле для оттачивания навыков парсинга. Да и, — если честно, — скучно в нескольких постах подряд писать на одну тему, буду чередовать.

Итак, к теме.

Впервые я натолкнулась на дублированные ветки форума года 2 назад, когда разбиралась с CMS Joomla. Тогда я просто отметила для себя этот факт: типа, кто-то просто по-своему решает проблему непопулярности форума и наполняет его за счет других ресурсов, паразитируя на чужой аудитории. Но, по сути, первоначальное заполнение форума полезной информацией — это очень неплохо для привлечения на форум целевой аудитории. Единственно, что надо бы не полностью копировать, а хоть немного видоизменять записи (достаточно пропустить через примитивный синонимайзер или разбавить взятыми со стороны).

Я знаю, что существуют генераторы дорвеев в виде форумов. Но что если вам нужен не дорвей, а форум "для людей"? Установить PhpBB — это самое малое. Главное — привлечь пользователей. А на пустое место никого не привлечь.

Итак, попытаемся его самостоятельно наполнить. Я разберу наполнение форума на движке PhpBB. Так как параллельно занимаюсь еще парой направлений, то не знаю, с какой частотой буду публиковать статьи по этой теме. Но то, что они будут — это факт.

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

Затем нужно создать разделы. Побродить в сети по форумам аналогичной тематики, посмотреть, подумать, оригинально сформулировать. В это же время надо начать думать над структурой приложения. Первое, что мне приходит в голову, это держать 2 базы MySQL: одну на локальной машине, а другую — в сети. И грамотно организовать взаимодействие этих баз.

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

На следующем этапе надо подыскать форумы, родственные по тематике. Желательно, чтобы они были на одном и том же движке (это освободит от необходимости составлять для парсинга разных движков отдельные регулярные выражения). Провести парсинг информации. Нам необходимо МНОГО информации, с большим запасом. Эту информацию записать на локальную базу, изменить сами записи, изменить время публикации (равномерно распределить на определенный период). А потом — автоматически публиковать ее в сети, опираясь на время записей, чтобы поисковики видели обновляющийся ресурс.

Наверное, немного плохо сформулировала. Но в голове я ясно представляю весь этот процесс.

Поэтапно буду освещать его здесь. Первые 3 вопроса будут:
1. Работа с MySQL в Delphi
2. Парсинг базы аватаров
3. Наполнение базы юзеров

Остальные пункты допишу потом.

Автоматизация постинга в дневники на блогхостингах с WordPress. Часть II

Часть I здесь.

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

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

- Сообщения на темы дневника, не опубликованные в этом дневнике
- Сообщения на темы дневника, не опубликованные нигде
- Любые неопубликованные сообщения
- Все сообщения

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

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



Свойства каждого дневника можно просмотреть и изменить (пароль, темы, описание).

(На форме у меня несколько закладок, но на остальных пока пусто — но там, по логике, в последствии обязательно что-то появится ;) )

Вот, в принципе, все, что надо сделать на этом этапе. Работы немало. Но она несложная, хоть и кропотливая: разместить компоненты, написать запросы и обработчики. Приступаем :) Как только все сделаем — останется самая малость: непосредственный постинг.

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

Да, я у каждого сообщения в базе ввела атрибут IS_HTML. Почти везде сейчас есть возможность вставлять в блоги html, только надо переключится... Надо подумать, как сделать так, чтобы в дневники можно было автоматом публиковать хоть текст, хоть html.

Автоматизация постинга в дневники на блогхостингах с WordPress. Часть I

Итак, эта тема относится не столько к парсингу, сколько к автоматизации ручного труда :) Но придется кое-что поанализировать, так что в любом случае навыки даром не пропадут.

Итак, цель (промежуточная): написать программу, которая логинится на блогхостинге (в частности, на основе WP) и отправляет сообщение в дневник. Как всегда в таких случаях, в основу хочется вложить хотя бы зачатки универсальности. Берем ручку и бумагу и садимся рисовать структуру БД (поразмыслив, легко прийти к выводу, что простым INI или XML-файлом не обойтись). Кто привык работать с пакетами CASE-средств, может открыть соответствующий программный продукт.

У меня получилось что-то вроде:



Не обращайте внимание на качество схемы :) ERWin отказался воспринимать название полей кириллицей, а стрелки вообще пришлось фотошопить) Все-таки лучшие инструменты — это бумага и ручка.

Итак, база будет состоять из следующих таблиц:
- Таблица блогхостингов
- Таблица дневников
- Таблица тем
- Таблица связей дневников и тем
- Таблица сообщений
- Таблица публикаций сообщений

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

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

Выбираем СУБД. Я остановила свой выбор на Firebird (бесплатная, знакомая, совместима с установленной InterBase, есть компоненты для работы... кстати, в PHP тоже есть библиотеки работы с этой СУБД). С таким же успехом вы можете выбрать любую СУБД, с которой привыкли работать... вплоть до MySQL.

Создаем БД (не забывая про индексы).

Следующим шагом будет создание интерфейса. Но это уже не сегодня. :)

Часть II здесь.