Мы будем Вам признательны, если Вы поддержите проект Open SLAED и используя Ваши возможности, разместите наш пресс-релиз на страницах своих сайтов, проектов, форумов, блогов. Текст пресс-релиза, возможно, видоизменить под Ваш формат, не искажая смысл. Пресс-релиз можно взять на данной странице.
Система была задумана как безопасная, скоростная, функциональная, гибкая в использовании, а главное простая для понимания рядовых пользователей с начальным уровнем знаний. Основные замыслы, которые были реализованы в системе, это снижение нагрузки на базу данных и сервер, повышение функциональности и безопасности, удобство управления и работы с системой, интуитивно понятный интерфейс, простота в использовании и расширении, то есть написании своих тем оформления, блоков, модулей и дополнений. Таким образом, система предназначена для максимально широкого спектра использования и предоставляет возможность построения на своей основе любого сайта, начиная от персональной странички или презентации компании и заканчивая мощными, высоко посещаемыми порталами.
Открыть файл config/config_global.php и изменить в нем значение $conf['close'] = "1"; на $conf['close'] = "0"; Значение 1 отвечает за закрытие сайта на профилактику, значение 0, соответственно за его свободный доступ для посетителей.
Определимся со значением и происхождением слов «Wares» и «Nulled».
Варез, произошло от «Wares», а оно в свою очередь от «Software», то есть программное обеспечение. Варез в узком смысле — это компьютерные программы, распространяемые пиратами с уже отключённой системой защиты от нелегального использования.
Нуленная или нуллед, произошло от слова «Nulled», в переводе (обнулена, удалены компоненты, защищающие скрипт от нелегального использования, а так же упоминание об авторском праве разработчиков и авторов). Как правило, данный термин используется пиратами для распространения ворованных скриптов.
Сайт татар Челябинска. Лента новостей из жизни Челябинских татар. Новости, знакомство, татарский чат, значение татарских имен, национальная борьба на поясах Кореш, обучение татарскому, арабскому языкам. Молодежный центр "Берлек".
Представляю Вашему вниманию новый форум системы, который войдёт в стандартный пакет Pro версии. Форум отвечает основным потребностям, при этом имеет минимально возможное количество кода.
Основным функционалом нового форума предусмотрено создание тем, ответов в темах посетителями и пользователями проекта. Вкратце, это основной функционал, такой, каким Вы его знаете из других форумов. Единственное что хотелось бы отметить, это неограниченная вложенность категорий (Форум в форуме), рейтинг созданных тем, возможность создания дополнительных полей, временное программирование тем и сообщений, а так же редактирование существующих сообщений без перезагрузки с использованием AJAX.
Разграничение прав
Администратор форума имеет следующие возможности
Вносить изменения в темы и сообщения
Программирование на время тем и сообщений
Удаление тем и сообщений
Смена даты публикации тем и сообщений
Закрытие тем и сообщений
Видимость закрытых тем и сообщений
Производить ответы в закрытых темах и сообщениях
Перемещать тему в другой форум
Модератор форума имеет следующие возможности
Вносить изменения в темы и сообщения
Программирование на время тем и сообщений
Удаление тем и сообщений
Смена даты публикации тем и сообщений
Закрытие тем и сообщений
Перемещать тему в другой форум
Действия модератора
Посетители и пользователи имеют права, установленные администратором. Для каждой категории форума возможна установка следующих прав в зависимости от пользователя или принадлежности пользователя к той или иной группе.
Смотреть (Видеть форумы и название тем)
Все
Пользователи
Группа
Специальная группа
Администраторы
Читать
Все
Пользователи
Группа
Специальная группа
Администраторы
Создавать темы
Все
Пользователи
Группа
Специальная группа
Администраторы
Отвечать в темах
Все
Пользователи
Группа
Специальная группа
Администраторы
Изменять свои темы и сообщения
Пользователи
Группа
Специальная группа
Администраторы
Удалять
Пользователи
Группа
Специальная группа
Администраторы
Модерировать
Специальная группа
Администраторы
Типы и значение групп
Группа (Попадание в группу зависит от количества набранных пунктов на проекте)
Специальная группа (Добавить пользователя в группу может только администратор проекта)
Для категорий форума могут быть установлены права доступа для нескольких групп одновременно.
Быстрое редактирование форума с AJAX
Обратите внимание на новую возможность быстрого редактирования сообщений форума. Работу функции редактирования без перезагрузки можно проверить непосредственно на нашем форуме.
Вид редактирования для администратора
Новый форум будет поставляться в стандартном пакете системы, начиная с версии 4.3 Pro. На данный момент оценить работу форума можно непосредственно на нашем проекте.
Завершён основной этап работы над новой версией системы SLAED CMS 4.2 Pro. На данный момент производятся заключительные настройки и корректировки для окончательной сборки архива. В данной версии системы появились новые возможности, улучшен функционал системы в целом, модифицированы проблемные и неудобные участки, реализованы новые модули. Особый акцент при работе над данной версией был сделан на безопасность, произведены значительные модификации, максимально снижающие уязвимость системы. По этой причине всем пользователям и клиентам настоятельно рекомендуется произвести обновление до этой версии. Более детальную информацию можно получить при подробном просмотре.
Новые возможности, модификации, общие изменения
Реализована новая возможность GZip и BZip2 сжатия файлов при использовании BB Редактора, а так же файлового редактора панели администратора системы.
Модифицирована функция сохранения лог файлов ошибок, динамических ошибок, запрещённых действий и нападений на систему. После того как лог файл набирает размер более 1 МБ, он автоматически упаковывается в GZip или BZip2 архив. Тем самым уменьшается размер лог файлов, экономится место на сервере, уменьшается скорость загрузки.
Обновлен до актуального уровня файл базы данных географического местонахождения IP адресов.
В модуль магазина добавлена новая функция, реализующая возможность экспорта и импорта баз данных продуктов, клиентов и партнеров магазина в формате CSV. Данный текстовый формат, предназначенный для представления табличных данных. Программы для редактирования файлов этого формата: Microsoft Excel, OpenOffice.org Calc, Numbers, TablePro, CSVed, KSpread, импорт и экспорт файлов такого типа возможен во многих инженерных пакетах, например ANSYS, LabVIEW и др.
В блок системной информации добавлены значения установленных на сервере возможностей GZip и BZip2 сжатий.
В состав пакета вошёл новый модуль «Помощь». Данная разработка будет весьма интересна и полезна для коммерческих проектов, а так же проектов, направление которых связанно с оказанием поддержки пользователям. Основное предназначение модуля это предоставление технической поддержки посетителям и пользователям Вашего проекта.
Модифицирован пользовательский модуль, функция навигации вынесена в ядро системы, установлена автоматическая сортировка отделов для более удобной её адаптации к существующим размерам. Модифицированы пользовательские функции партнерского и магазинного отделов.
Модифицирован модуль автоматического обмена ссылок. Реализована новая функция подсчёта переходов работающая независимо от блока модуля и кэширования. Добавлены новый конфигурации для блока модуля обмена ссылками, такие как: Количество ссылок в блоке и их длинна.
Новая функция переходов с других сайтов отслеживает переходы во всех и во все участки сайта. В конфигурациях системы установлена возможность отключения, а так же сроки сохранения статистики переходов в днях.
В модуле автоматического обмена ссылок реализован новый анализатор переходов, который определяет переходы зарегистрированных пользователей проекта, поисковых систем, географическое расположение и IP адреса посетителей. Предоставляется широкий спектр анализа и сортировки переходов по различным параметрам, таким как: Идентичные переходы, Адреса переходов, Идентичные входы, Адреса входов, Идентичные имена перешедших, Имена перешедших, Идентичные IP перешедших, IP перешедших, Одновременные переходы, Время переходов, а так же в порядке убывания или возрастания.
Кардинальным модификациям подверглись функции установки и сохранения даты и времени публикаций, а так же другой информации связанной со временем. Теперь для установки даты используется удобный календарь, который упрощает установку даты и времени, а так же исключает установку не существующих дат. Изменениям подверглись все модули, и компоненты системы, где использовалась установка даты и времени.
Для администратора проекта написан и установлен новый модуль «Переходы», который отслеживает и анализирует все переходы с других сайтов на Ваш. Модуль определяет переходы зарегистрированных пользователей проекта, поисковых систем, географическое расположение и IP адреса посетителей. Предоставляется широкий спектр анализа и сортировки переходов по различным параметрам, таким как: Идентичные переходы, Адреса переходов, Идентичные входы, Адреса входов, Идентичные имена перешедших, Имена перешедших, Идентичные IP перешедших, IP перешедших, Одновременные переходы, Время переходов, а так же в порядке убывания или возрастания.
Во избежание путаницы произведено ограничение выбора модулей при добавлении и редактировании категорий. Теперь установка категорий возможна только для тех модулей, в которых они предусмотрены.
Установлена новая версия HTML редактора Tiny MCE 3.1. Изменены функции подключения в связи с новым методом интеграции, удалены старые участки и файлы подключения старой версии.
Реализована новая возможность установки редактора персонально для каждого администратора проекта. Редактор устанавливается при добавлении нового администратора, так же возможна смена редактора для уже существующих администраторов.
Реализована новая возможность использования редакторов в пользовательском отделе. Теперь можно выбрать какой редактор будет предложен посетителям, в комментариях, в публикациях или других отделах. Возможные варианты: BB Редактор, HTML Редактор Tiny MCE или без редактора.
Установлена новая возможность конфигурации формы обратной связи с администраторами проекта. Теперь Вы можете решать, каким из Ваших администраторов пользователи могут отправлять письма по средствам модуля контактов. Настройка устанавливается персонально для каждого администратора проекта.
Исправления и корректировки
Реализована поддержка человека понятных урлов для всех модулей и отделов системы. Исправлены неточности, доработаны и модифицированы некоторые участки.
Удалены лишние параметры в конфигурациях панели администратора модуля новостей.
Решена проблема, связанная с некорректной работой рейтинга в случае его отключения в панели администрирования рейтингом.
В конфигурациях системы удалены настройки связанные с использованием Cookies администратора в виду отсутствия их необходимости.
Решён вопрос с заслешиванием одинарных и двойных кавычек при публикации материала в пользовательской части проекта. Частично изменена логика фильтрации входящей информации и её основные функции.
Повышение уровня безопасности
Значительным образом переписан принцип авторизации администраторов системы. С данного момента авторизация и определение администратора через Cookies больше не используются в виду низкого уровня безопасности данного способа, работа с администраторами переведена на безопасные сессии.
Модифицирована функция определения главного администратора системы, повышен уровень безопасности её использования.
В модуле пользователя удалена возможность загрузки аватара с удалённого сервера в виду потенциальной уязвимости данного метода.
Модифицирована функция загрузки файлов на сервер, устранены некоторые неточности связанные с безопасностью. Модификации подверглись участки, и модули где используется данная функция.
Модифицирована функция определения браузера пользователя. Установлен фильтр, который устраняет возможность подмены данных на инъекцию или вредоносный код.
В целях повышения безопасности в модуле загрузки файлов удалена возможность загрузки удалённого файла с Другова сервера, таким образом, устранена возможность подмены или манипуляции загружаемого файла.
Частично переписан модуль рекомендаций, устранены и модифицированы потенциально опасные к уязвимостям участки кода.
Проработаны все модули системы, имеющие потенциально опасные участки кода, установлены соответствующие фильтры, препятствующие инъекциям и вредоносным внедрениям.
Начиная с 22.06.2008, новую версию можно будет приобрести, в магазине нашего проекта. Обновление для актуальных клиентов профессиональной версии можно будет загрузить в персональном отделе клиентов.
Определимся со значением и происхождением слов «Warez» и «Nulled». Варез, произошло от «Wares», а оно в свою очередь от «Software», то есть программное обеспечение. Варез в узком смысле — это компьютерные программы, распространяемые пиратами с уже отключённой системой защиты от нелегального использования. Нуленная или нуллед, произошло от слова «Nulled», в переводе (обнулена, удалены компоненты, защищающие скрипт от нелегального использования, а так же упоминание об авторском праве разработчиков и авторов). Как правило, данный термин используется пиратами для распространения ворованных скриптов.
Как появляется нуленная или варез версия?
Пираты, под видом честных граждан приобретают одну версию на легальной основе или выкрадывают её у клиентов купивших систему. Далее производят удаление компонентов защищающих данный скрипт от нелегального копирования. Как правило, удаляют упоминание о разработчиках и авторах системы, так называемые «Копирайты». Не редко за место оригинальных вставляют свои и распространяют скрипт для собственной наживы или других корыстных целей.
Какие последствия могут быть за использование и распространение варез или нуленных версий?
Программы и скрипты защищены законом Российской федерации об авторском праве. По закону Российской федерации Вы можете быть привлечены к уголовной ответственности за использование или распространение нелегальных программ или скриптов. Ответственность несут не только распространители нелицензионных продуктов, но качающие и раздающие пользователи, то есть даже за публикацию ссылки на «Warez» программу или «Nulled» скрипт, Вам грозит до 6 лет лишения свободы!
Что дают варез или нулленные версии их пользователям?
Ворованные и распространяемые версии могут быть не безопасными для использования. По причине того, что в них могут находиться «Вирусы», «Трояны» или другие шпионы, встроенные пиратами специально для реализации своих корыстных целей. Были случаи, когда пираты встраивали в систему специальные скрипты, выжидали пока тот или иной пользователь выстраивал на ней свой проект и после чего шантажировали его или просто удаляли сайт.
Как было описано выше, за использование ворованной версии Вы можете быть привлечены к уголовной ответственности. Соответственно Ваш сайт может быть удалён хостером или датацентром в случае подачи заявки авторами системы.
Вы не имеете технической поддержки от авторов и разработчиков системы в случае возникновения тех или иных вопросов связанных с ней. Ко всему этому, Вы скорей всего будете заблокированный на проекте разработчиков, и не будете иметь доступ к актуальной информации связанной с развитием, обновлением и другими изменениями.
Какие потери несут авторы и разработчики из-за нуленных или варез версий?
Ворованные версии приносят невозместимый ущерб не только авторам и разработчикам системы, но и всем пользователям и клиентам. Дело в том, что основная сумма, полученная с продажи системы, идёт на разработку новых функций, улучшение оформления, поддержку проекта, оплату работы программистов и дизайнеров, оплату сервера, его программного обеспечения, и всего того, что связанно с проектом и системой в целом. Тем самым они воруют не только у нас, но и у всех Вас, пользователей и клиентов системы.
В серии статей "Ten Security Checks for PHP" кратко рассматриваются 10 наиболее часто совершаемых PHP программистами ошибок, приводящих к проблемам с безопасностью скриптов.
Избегайте использования переменных сформированных на основании данных пользователя в функции включения файла (include, require) или доступа к файлу (readfile, fopen, file). Например: include($lib_dir . "functions.inc"); include($page); переменные $lib_dir и $page перед этим нужно проверить либо на предмет наличия запрещенных символов, либо сопоставить с заранее определенным массивом допустимых значений.
if (!(eregi("^[a-z_./]*$", $page) && !eregi("..", $page))) {
die("Invalid request");
}
Необходимо экранировать опасные символы ( и ') в переменных участвующих в SQL запросах. Например, злоумышленник может передать переменную вида "password=a%27+OR+1%3Di%271" которая будет использована в SQL запросе как "Password='a' or 1='1'". Решение: включить magic_quotes_gpc в php.ini или экранировать переменные самостоятельно через addslashes();
Никогда не нужно доверять глобальным переменным, при включенном в php.ini режиме register_globals злоумышленник может подменить значение глобальной переменной. Используйте ассоциативные массивы $HTTP_GET_VARS и $HTTP_POST_VARS с выключенным register_globals и в начале скрипта явно инициализируйте все глобальные переменные.
Определяйте местонахождение закаченного файла только через is_uploaded_file() или используя move_uploaded_file(), но не доверяйте глобальной переменной с путем к закаченному файлу, значение которой злоумышленник может подменить.
Используйте функции htmlspecialchars(), htmlentities() для экранирования HTML тэгов присутствующих в данных полученных от пользователя.
Защищайте библиотеки функций от просмотра их исходных текстов пользователем (расширения .inc, .class). Решение: снабжайте библиотеки расширением .php, помещайте в закрытую директорию или настройте хэндлер для парсинга расширения файлов с вашими библиотеками.
Помещайте файлы данных вне дерева файловой системы доступной через web (уровнем ниже htdocs, или "document root") или защищайте директории через .htaccess.
mod_php запускайте в режиме safe_mode.
Проверяйте наличие запрещенных символов в переменные используемых в функциях eval, preg_replace, exec, passthru, system, popen, ``.
При использовании не mod_php, а CGI варианта php.cgi не забывайте, что через php.cgi можно получить доступ к любому файлу в директориях защищенных через .htaccess, так как доступ в этом случае ограничен только для прямых запросов, но не для запросов через CGI скрипт php.cgi.
Все, изложенное мной, является плодом более чем 3-летнего опыта в области оптимизации сайтов и практических наблюдений. Таким образом, мои рекомендации будут носить в большей степени субъективный практический характер, чем теоретический. Сразу предупреждаю, что все мои советы актуальны для владельцев серьезных тематических ресурсов, а не всяких дурацких развлекательных порталов, цель которых – привлечь абы кого, чтобы только заработать баннерные показы или накрутить счетчик.
Продвижение сайта - Заголовки
Итак, я открываю серию статей, посвященных продвижению интернет-сайта в сети. Все, изложенное мной, является плодом более чем 3-летнего опыта в области оптимизации сайтов и практических наблюдений. Таким образом, мои рекомендации будут носить в большей степени субъективный практический характер, чем теоретический. В моих статьях я не буду тратить время на всякие системы накрутки счетчиков, обмена посетителями и прочую подобную фигню. Продвижение в моем случае прежде всего означает оптимизацию страниц сайта под поисковые роботы + различные советы и тонкости из практики. Надеюсь, вам будет интересно и кому-нибудь мои советы даже помогут в увеличении целевой аудитории, посещающей ваш сайт.
Будем считать, что вы хорошо владеете программированием на HTML и знаете, для чего нужны различные тэги и куда их пихать, поэтому на технической стороне я не буду заострять внимание. Говоря о заголовке, я имею в виду содержание страницы от тэга ‹HEAD› до тэга ‹/HEAD›. Напомню, что структура стандартной страницы представляет из себя примерно следующее:
Как раз о верхней части страницы и пойдет речь в этой статье, т.е. подробно о тегах TITLE и META.
TITLE
Надеюсь, вы уже догадались, что TITLE – это титул страницы. Пользователь видит его в верхней части окна браузера. Тэг TITLE прежде всего имеет важное значение при оптимизации страницы под поисковые машины. Все без исключения поисковые роботы обрабатывают значение TITLE и в соответствии с его содержанием формируют перечень ключевых слов и фраз страницы. Таким образом, титул должен отражать реальное содержание страницы или сайта. Однако при заполнении этого параметра многие совершают следующие ошибки:
Начинают перечислять перечень ключевых слов. Современные поисковые роботы стали гораздо сообразительней, чем раньше и в большинстве случаев им удается распознать, что в титуле написана белиберда, а не четкое и внятное содержание страницы. Это может привести к тому, что поисковик проигнорирует титул при индексации;
Вбивают текст размером с первый том "Капитала" Карла Маркса. Дело в том, что поисковые роботы серьезно относятся к содержимому тэга TITLE, но обычно индексируют первые 25-50 символов. Таким образом, оставшаяся писанина только напрасно увеличивает объем страницы и время загрузки;
Перегружают титул спецсимволами (запятыми, кавычками, тире и пр. знаками). Спецсимволы в TITLE не индексируются поисковыми роботами, так что их использование лучше свести к минимуму, или вообще постараться обойтись без них;
Пишут содержание TITLE прописными (заглавными) буквами. Многие поисковики этого не любят. Так что лучше их не злить понапрасну и писать нормально. От того, что вы напишете титул прописными, заметней для поисковика вы не станете!
В общем, рекомендую перед заполнением тэга TITLE как следует подумать, о чем ваш сайт и выразить его тематику в 2-3 веских словах в виде словосочетания.
META
О тэге META у нас будет разговор серьезный. Прежде всего необходимо понять, что META-тэги являются важной составляющей в странице и их правильное использование может как поднять популярность страницы, так и оказать обратное воздействие.
META-тэги делятся на две группы: контролирующие отображение страницы браузером и служащие ценной информацией для поисковых машин. Первая группа тэгов вводится следующим образом:
‹META HTTP-EQUIV="параметр" CONTENT="значение"›
Я не буду заострять внимание на этом виде META-тэга, т.к. моя задача – рассказать, как сделать страницу доступной, а не как сделать, так, чтобы она правильно отображалась браузером. Но чтобы вы поняли, для чего нужны эти META-тэги, приведу несколько примеров их использования:
Указывает, в какой кодировке должна выводиться страница (в данном случае: windows-1251). Также возможны значения (в поле CHARSET): koi8-r, iso-8859-5, iso-8859-1 и т.д.
Указывает типы переменных, содержащихся на странице (в данном случае: текст и JavaScript™). Возможные значения: text, javascript, php и т.д.
‹META HTTP-EQUIV="pragma" CONTENT="no-cache"›
или
‹META HTTP-EQUIV="no-cache›
или
‹META HTTP-EQUIV="cache-control" CONTENT="no-cache"›
или
‹META HTTP-EQUIV="expires" CONTENT="wed, 2 mar 1996 00:00:05 GMT"›
Запрет на кэширование браузером страницы. Тэг актуален в том случае, если содержимое страницы часто меняется. В этом случае браузер будет при каждом обращении к странице заново ее кэшировать.
Сообщает браузеру язык, на котором написана страница (в данном случае: английский и русский). Возможно указать и один язык (например, только "ru") или несколько через запятую. Сразу скажу, что этот тэг актуален только для очень старых браузеров, а новые на него внимания не обращают, так что лучше его избегать.
Принудительно осуществляет переход на указанную страницу через определенное количество секунд (в данном случае: переход на страницу "http://yandex.ru/index.html" через 5 секунд).
Существует еще с десяток META HTTP-EQUIV тэгов, но, на мой взгляд, они бестолковые и не оказывают существенного влияния на отражение страницы. Или предназначены для устаревших версий браузеров, которые практически уже не используются. Советую не увлекаться такими тэгами и обратить внимание прежде всего на первый пример, выдающий кодировку документа – он является обязательным; остальные же используйте только по необходимости!
Второй тип META-тэгов вводится следующим образом:
‹META NAME="параметр" CONTENT="значение"›
Эти META-тэги никак не влияют на отображение страниц сайта, но играют важную роль в предоставлении информации поисковым роботам и указывают на алгоритм индексирования. В общем, служат чем-то вроде паспорта для страницы. Поскольку известно, что основная доля трафика генерируется поисковыми роботами, необходимо отнестись с полным сурьезом к заполнению значений этих тэгов. Ниже я привожу примеры значений с необходимыми комментариями:
‹META NAME="description" CONTENT="..."›
В поле CONTENT вы должны ввести краткое описание документа. Ни в коем случае не строчите трактат длинной в жизнь и не перечисляйте ключевые слова! Правильным будет написание небольшого предложения длинной до 200-250 символов, в котором повествуется, о чем ваш сайт (страница) и что на нем можно найти. Избегайте большого количества спецсимволов, слов из прописных букв и бессмыслицы (например, "Это чумовой сайт! Все сюда!"). Содержание параметра DESCRIPTION часто отражается в результатах поиска и вносится в базу данных поисковика. Так что чем точнее и лаконичней будет сформулировано описание сайта, тем лучше!
‹META NAME="keywords" CONTENT="..."›
В поле CONTENT вы должны внести через запятую (!) перечень ключевых слов и фраз, в соответствии с которым будет строиться запрос поисковым роботом. Только не надо вносить весь словарь Ожегова и/или Даля! Во-первых, поисковики обычно обрабатывают только первые n-цать символов в строке CONTENT (в среднем до 500). Во-вторых, ключевые слова и фразы должны отражать реальное содержимое страницы. В противном случае поисковый робот отсекает ненужное и часть содержимого KEYWORDS просто зазря засоряет страницу. Существует расхожее мнение, что сейчас поисковые роботы практически не уделяют внимания значению параметра KEYWORDS. Действительно, в процессе эволюции поисковики стали меньше обращать внимания на ключевые слова, потому что многие нехорошие люди занимались банальным поисковым спамом и вносили в KEYWORDS совсем не то, что было отражено на странице. Тем не менее, актуальность этого META-тэга еще до конца не утрачена и заполнять его все-таки рекомендуется.
Сообщает поисковому роботу частоту обновлений содержимого. В соответствии с этим страница может быть статичной (static), т.е. обновления происходят время от времени, редко или совсем не происходят; или динамичной (dynamic), которая обновляется часто (например, страница новостей). В поле CONTENT необходимо записать только одно из значений ("static" или "dynamic"), в соответствии с характером страницы. Некоторые "умники" пытаются обдурить поискового робота, объявляя статичную страницу динамичной, в надежде на то, что ее рейтинг повысится. Поисковик очень быстро вычисляет таких мошенников, отслеживая дату изменения файла страницы и характер изменений ее содержимого. В итоге можно отправиться в бан-лист, из которого путь будет не так прост. Чтобы этого не произошло, постарайтесь либо писать правду, либо вообще не употреблять этот параметр. Без него поисковик тоже в состоянии разобраться, какая эта страница и как часто ее переиндексировать.
‹META NAME="revisit-after" CONTENT="..."›
Тэг почти аналогичен предыдущему и указывает, через какой промежуток времени поисковик должен переиндексировать страницу. Опять-таки лучше не дразнить поискового робота и указывать реальное значение. Если у вас не лента новостей с ежедневным, еженедельным или прочим регулярным обновлением, то лучше этот параметр вообще не использовать. Если все-таки возникла такая необходимость, то значения поля CONTENT могут быть такими: day (пример: 1 day), days (пример: 7 days), week (пример: 1 week), weeks (пример: 2 weeks), year (пример: 1 year), years (пример: 5 years). Выражать промежуток времени можно различными значениями, но только одним из них. Например, 1 год можно записать как "1 year" или "365 days", или "52 weeks". Но недопустимо употребление сразу нескольких значений. Например, "1 year 2 weeks 3 days"!
‹META NAME="robots" CONTENT="..."›
Это очень важный тэг, который указывает поисковику, каким образом ему необходимо индексировать страницу. Возможные значения поля CONTENT:
index, follow – индексировать страницу и все ссылки на ней
index, nofollow – индексировать страницу, не индексировать ссылки
noindex, follow – не индексировать страницу, а только ссылки
noindex, nofollow – не индексировать страницу, не индексировать ссылки
all – равнозначен index, follow
none – равнозначен noindex, nofollow
Если вам все равно, как поисковый робот будет индексировать содержимое страницы, то лучше вообще этот параметр не использовать, т.к. в этом случае поисковик определит наиболее оптимальный и эффективный способ индексации. Если вдруг вам необходимо запретить на индексацию часть содержимого страницы, а другую оставить, то необходимо поместить запрещенный для поисковых роботов блок в тэг ‹NOINDEX›...‹/NOINDEX›. В этом случае META-тэг с параметром "robots" использовать не надо.
Существует еще целая куча META-тэгов подобного вида, всесторонне описывающая содержимое страницы, включая данные о ее создателе, генераторе, классификации и т.п. Отталкиваясь от практического опыта могу заметить, что ничего, кроме, засорения страницы и увеличения ее объема, они по сути не делают. Так что лучше ограничиться использованием вышеуказанных тэгов, которые являются основополагающими.
Итак, мы рассмотрели с вами основные требования к написанию заголовка страниц таким образом, чтобы их успешно и правильно индексировали поисковые роботы. Если вы все сделаете правильно, то уже через некоторое время (от 2 недель до месяца) вы заметите, что поисковые роботы стали лучше вас видеть и посетители стали лучше вас находить. Закрепляя вышесказанное, хочу привести пример, как может выглядеть идеальная для поисковика страница:
‹HTML›‹HEAD›‹TITLE›Справочник по META-тэгам‹/TITLE›
В SLAED CMS реализована и успешно используется универсальная система блоков, которая даёт гибкую возможность их использования. В отличие от стандартных блоков системы (Блоки создаваемые в базе данных, Файловые блоки или HTML Блоки) которые мы можем использовать независимо друг от друга, персонально для каждого модуля системы или контингента посетителей, в желаемом месте, мы имеем свободные, независимые блоки. Данный тип блоков можно использовать в любых местах, шаблонах или модулях системы.
Общие сведения
В системе есть два вида блоков:
- Стандартные (обычные).
- Свободные (fly, плавающие).
Создать новый стандартный блок можно через:
- Панель администратора >> Блоки и баннеры >> Управление блоками >> Добавить новый блок
Стандартные блоки могут размещаться (опция «Позиция»):
- Слева
- По центру вверху
- По центру внизу
- Справа
- Верхний баннер
- Нижний баннер
Стандартный блок может быть включён (опция «Отображать блок в модулях») в одном или в нескольких выбранных модулях, он может отображаться во всех модулях или только на главной страничке сайта.
Вновь созданный стандартный блок можно использовать для вывода RSS-новостей, для чего выбирается соответствующий RSS/RDF файл.
Оформление внешнего вида блоков с помощью шаблонов
Стандартные блоки системы
Файл block-center.html отвечает за верхние центральные блоки.
Файл block-down.html отвечает за нижние центральные блоки.
Файл block-left.html отвечает за левые блоки.
Файл block-right.html отвечает за правые блоки.
Файл block-all.html отвечает за все остальные блоки, которые могут использоваться отдельно от стандартных.
Можно создать уникальное оформление для любого блока, находящегося в директории blocks/ (block-name.php; name - это имя блока). В директории templates/ваша_тема/ создаём файл шаблона с именем block-name.html. В этом шаблоне делаем уникальное оформление для блока block-name.php. Пример: нужно сделать уникальное оформление для блока block-voting.php. В этом случае создаём файл шаблона в директории templates/ваша_тема/ с названием block-voting.html. Система найдёт этот файл шаблона автоматически, а затем будет использовать его только для оформления блока block-voting.php.
Стандартные блоки имеют более высокий приоритет, чем свободные блоки, поэтому если в свободном блоке отмечено чтобы он отображался хотя бы в одном модуле или в нескольких модулях или во всех модулях или на главной страничке сайта, то такой блок автоматически превращается в стандартный несмотря на то, что он отмечен как «Свободный блок» (fly block).
Свободные блоки системы
Свободный блок (fly) можно разместить в любом месте странички сайта, для чего требуется вставить код формирования этого свободного блока в соответствующий php-файл (в config/config_header.php, например). В шаблоны тем оформления (файлы *.html) нельзя вставлять код формирования свободного блока, так как в этом случае этот php-код не будет обрабатываться.
Свободный блок описывается в php-скрипте функцией: blocks("why", "who");
blocks - функция создания свободного блока с параметрами: why и who.
В зависимости от параметров why и who функция создания свободного блока может:
- Печатать на стандартный вывод сформированный свободный блок (выводить блок на страничку).
- Возвращать строку со сформированным свободным блоком (вывод блока в переменную для последующей вставки этого блока в html-шаблон).
При этом этот свободный блок может быть с оформлением или без него - это зависит от параметров why.
Значение параметров why
none (выводит тело блока на страничку без оформления)
$fly_block_1_1 = blocks("none", 15);
$fly_block_1_2 = blocks("none", "block-menu2.php");
standart (выводит тело блока на страничку с оформлением)
$fly_block_2_1 = blocks("standart", 15);
$fly_block_2_2 = blocks("standart", "block-menu2.php");
plzreturn (выводит тело блока в переменную без вывода на страничку и без оформления)
$fly_block_3_1 = blocks("plzreturn", 15);
$fly_block_3_2 = blocks("plzreturn", "block-menu2.php");
oreturnform (тело блока в переменную без вывода на страничку, но с оформлением)
$fly_block_4_1 = blocks("oreturnform", 15);
$fly_block_4_1 = blocks("oreturnform", "block-menu2.php");
* 15 - Это bid, номер блока в базе данных (Номер блока можно посмотреть в панели администратора в строке №).
Значение параметров who
bid блока (номер блока в базе данных; таблица slaed_blocks, поле bid; это так называемый без файловый блок, то есть код этого блока находится не в php-файле в директории blocks, а в базе данных в таблице slaed_blocks в поле content)
$fly_block_5_1 = blocks("none", 15);
$fly_block_5_2 = blocks("standart", 15);
$fly_block_5_3 = blocks("plzreturn", 15);
$fly_block_5_4 = blocks("oreturnform", 15);
block-name.php (имя php-файла блока; name - это имя блока)
$fly_block_6_1 = blocks("none", "block-menu2.php");
$fly_block_6_2 = blocks("standart", "block-menu2.php");
$fly_block_6_3 = blocks("plzreturn", "block-menu2.php");
$fly_block_6_4 = blocks("oreturnform", "block-menu2.php");
Чтобы пользоваться созданным свободным блоком нужно, чтобы этот блок был активным. На этом блоке должна быть только одна отметка - «Свободный блок», в противном случае этот блок будет стандартным.
Для формирования эксклюзивного оформления для свободного блока нужно создать файл шаблона этого блока с именем:
- fly-block-15.html (15 - это номер блока в базе данных (таблица slaed_blocks, поле bid));
- fly-block-name.html (name - это имя блока).
Пример 1
Нужно создать свободный блок с параметрами:
- Вывод тела свободного блока на страничку.
- Без оформления.
- По номеру блока в базе данных.
- C использованием имени блока.
Пример 2
Нужно создать свободный блок с параметрами:
- Вывод тела свободного блока на страничку.
- С оформлением.
- По номеру блока в базе данных.
- С использованием имени блока:
Пример 3
Нужно создать свободный блок с параметрами:
- Вывод тела свободного блока в переменную.
- Без оформления.
- По номеру блока в базе данных
- С использованием имени блока:
Пример 4
Нужно создать свободный блок с параметрами:
- Вывод тела свободного блока в переменную.
- С оформлением.
- По номеру блока в базе данных.
- С использованием имени блока.
Для вывода на страничку переменной, содержащей в себе тело свободного блока, нужно сделать следующее:
Открываем файл config/config_header.php и в него вставляем код:
В любое место шаблона (в templates/ваша_тема/index.html, например) вставляем массив $BlockGlob[menu2] (Обратите внимание на отсутствие кавычек внутри квадратных скобок!) На страничку вместо $BlockGlob[menu2] будет выведен блок menu2, код которого содержится в файле blocks/block-menu2.php.
Для корректного вывода на страничку свободного блока, который из базы данных запрашивается по bid из таблицы slaed_blocks, при включённом модуле rss_info (вывод новостей в формате RSS) нужно в php-файл config/config_header.php записать:
Свободный блок может выводиться на странички сайта на всём сайте, если его код встроен в тему оформления, или он может выводиться в каком-то определённом модуле, если его код встроен в код этого модуля.
Свободный блок не может быть обработан системой как стандартный блок, но стандартный блок может быть обработан системой как свободный блок. Пример: блок modules, имеющий bid 1 (таблица slaed_blocks), можно вывести на страничку ещё раз как свободный блок, и тогда на этот блок накладываются все те ограничения, которые наложены на блок modules (показывать только на главной страничке сайта или только в одном модуле или в выбранных модулях или во всех модулях).
Использование уникального стиля оформления для блоков
Стандартные блоки
1) Если существует эксклюзивное оформление для блока block-name.php, то применяется оно. Оформление для блока берётся из:
- Файла templates/ваша_тема/block-name.html по имени блока (name).
- Из файла templates/ваша_тема/block-15.html, где 15 - это номер блока (поле bid в таблице slaed_blocks).
2) Если существует оформление для верхних/нижних или левых/правых блоков, то применяется оно. Оформление для блока берётся из:
3) Если не существуют шаблоны, описанные в п. 1) и п. 2), то для оформления блока применяется шаблон templates/ваша_тема/block-all.html.
4) Если шаблон templates/ваша_тема/block-all.html отсутствует, то применяется встроенное оформление блоков (файл function/template.php):
Тэги fieldset и legend описаны в стилевом файле templates/ваша_тема/style.css.
Свободные (fly) блоки
1) Если существует эксклюзивное оформление для свободного блока fly-block-name.php, то применяется оно. Оформление для блока берётся из:
- Файла templates/ваша_тема/fly-block-name.html по имени блока (name).
- Из файла templates/ваша_тема/fly-block-15.html, где 15 - это номер блока (поле bid в таблице slaed_blocks).
2) Если существует общее для всех свободных блоков оформление (файл шаблона templates/ваша_тема/fly-block.html), то применяется оно.
3) Если не существуют п. 1) или п. 2), то применяется файл шаблона templates/ваша_тема/block-all.html.
4) Если шаблон templates/ваша_тема/block-all.html отсутствует, то применяет встроенное оформление блоков (файл function/template.php):
Тэги fieldset и legend описаны в стилевом файле templates/ваша_тема/style.css.
Чем меньше используется уникальных стилей (шаблонов) оформления для блоков, тем быстрее формируется и выдаётся пользователю страничка вашего сайта.
В этой публикации мы затронем те директивы, которые не успели охватить в предыдущих частях. Эти директивы не поддаются определению на уровне директорий. Это означает то, что вы должны иметь доступ к файлу конфигурации веб сервера Apache (httpd.conf).
Обычно такой доступ имеют пользователи «root» или администратор сервера.
Если вы хотите вести логи всех операций, выполненных с помощью mod_rewrite, можно активировать это с помощью следующей записи:
Эту строку нужно вписать в «Раздел 2: Конфигурация основного сервера» в файле httpd.conf, а не в .htaccess!
Все манипуляции, произведенные mod_rewrite будут записываться в этот файл. Имя лог файла может быть любым. Вы можете указать абсолютный или относительный (относительно ServerRoot) путь к файлу.
Если вы хотите вести разные лог файлы для различных виртуальных хостов, то нужно ввести изменения в «Раздел 3: Виртуальные сервера», например так:
RewriteLogLevel может быть определен в пределах диапазона от 1 до 8. Обычно достаточно первого уровня. Более высокие уровни используются для деббагинга.
Другая директива, которая является очень удобной в целях клоакинга – это так называемая карта перезаписи. Это – файлы, содержащие пары ключ/значение, обычно в формате текстового файла:
Ключи, как вы видите, имена хостов или IP адреса. В этом простеньком примере значение всегда одно – «spider». Естественно, в реальном файле значения будут другие. Эта директива может быть записана в второй («Конфигурация основного сервера») или третий («Виртуальные сервера») раздел файла httpd.conf:
«Карта перезаписи» возымеет эффект на весь сервер.
Также, в файл .htaccess записывается:
Данные условия будут производить системную проверку: произведен ли запрос поисковиком. С этой целью производится поиск по файлу spiderspy.txt. Если ключ найден, будет возвращено значение «spider», а «условие» будет являться истинным.
Затем выполняется первый RewriteRule. Это означает то, что запрашиваемая «.htm» страница будет отдана поисковику. Переменная $1 равна части в круглых скобках «^(. *).htm$», то есть имя файла останется тем же самым.
Если же URL вызван обычным посетителем, то применяется второе «правило»: пользователь будет перенаправлен на страницу «index.html».
Поскольку «.htm» страницы будут читаться только «пауками», они могут быть оптимизированы соответственно для поисковых серверов. Вы можете также использовать файл в формате «dbm» вместо обычного текстового файла. Бинарный формат данных позволяет ускорить поиск, который является особенно важным, если вы работаете с очень большими списками поисковиков. Пример, данный выше, предлагает простые функциональные возможности клоакинга. Все обычные посетители будут всегда переадресовываться к странице «index.html» и не будет вестись никаких логов файлов вне логов mod_rewrite.
Можно заменить несколько строчек кода php (perl и т.д.) в ваших приложениях, используя всего одну-две строки mod_rewrite. Последний пример проиллюстрирует это более подробно.
Цель – показать посетителям «фото дня». Посетитель, кликнувший по ссылке http://yoursite.com/pic.html увидит лучшую фотографию или картинку дня, и так каждый день. Мы будем работать с серверными переменными: TIME_MON, TIME_DAY
Поместим в файл .htaccess одну единственную строку:
Запрашиваемый URL будет перезаписан, например: pic-08-28.html, pic-08-29.html, pic-08-30.html и так далее.
Теперь, все что вы должны сделать – это единожды загрузить файлы с соответсвующими именами и забыть о ежедневном обновлении ссылки. Переменные времени также могут использоваться для другой периодичности.
Это был последний пример в серии публикаций о замечательном модуле mod_rewrite. Естественно невозможно было затронуть все нюансы, директивы, переменные и т.д. в данной публикации, целью было другое – дать общее представление и понимание основ, и так сказать «ввести в курс дела».
В двух предыдущих частях мы познакомились с основами «правил перезаписи» URL и «условиями правил». Позвольте предложить к рассмотрению два примера, иллюстрирующих более сложные приложения. Первый пример имеет дело с динамическими страницами, а второй показывает возможности вызова «.txt» файлов и произведение различных действий над ними.
Предположим, что у нас есть виртуальный магазин по продаже каких-то товаров. Клиенты обращаются к описаниям товаров через скрипт:
Эти адреса представлены как ссылки на большинстве страниц сайта.
А теперь допустим, что вы решили добавить сайт для индексации в поисковые системы. Тут вас поджидает небольшая неприятность – не все поисковики принимают, понимают и индексируют URL, в которых содержится символ «?».
Более естественным и приемлемым для поисковика является URL вида:
http://www.yoursite.com/cgi-bin/shop.cgi/product1
В данном случае символ «?» заменяется на «/».
Еще более комфортабельный URL с точки зрения поисковика будет иметь вид:
http://www.yoursite.com/shop/product1
Для поисковика, «shop» теперь как-бы является директорией, содержащей товары product1, product2 и т.д.
Если пользователь, со страницы результатов запроса в поисковике проследует по такой ссылке, то эта ссылка должна будет трансформироваться в ссылку: shop.cgi?product1.
Чтобы добиться такого эффекта можно использовать mod_rewrite, используя следующую конструкцию в файле .htaccess:
Переменные $1 и $2 составляют так называемые "backreferences". Они связаны с текстовыми группами. Вызываемый URL разбивается на части. Все, что находится перед «shop», плюс все что находится после «shop/» определяется и хранится в этих двух переменных: $1 и $2.
До этого момента, наши примеры использовали «правила» типа:
Однако мы еще не достигли истинной перезаписи URL адресов, в смысле того, что один URL должен перенаправлять посетителя на другой.
Для нашей записи вида:
применяется общий синтаксис: RewriteRule текущийURL перезаписываемыйURL
Как видите, эта директива выполняет действительную «перезапись» URL адреса.
В дополнение к записям в файл .htaccess, нужно еще заменить все ссылки на сайте, которые имеют формат «cgi-bin/shop.cgi?product», на ссылки вида: «shop/product»
Теперь, когда поисковик найдет страницу с подобными ссылками, он проиндексирует сайт без всяких видимых проблем.
Таким образом вы можете превратить чисто динамический сайт в сайт, имеющий статическую структуру, что явно принесет пользу в вопросе индексирования различными посковыми машинами. Обратите внимание на вид URL адресов на данном сайте. Вдобавок ко всему, они имеют еще и легкочитамую для человека структуру - ЧПУ (человекопонятный УРЛ). Но об этом мы поговорим в другой статье.
В нашем втором примере мы обсудим, как переадресовать запросы «.txt» файлов к сценарию программы.
Многие хостинг провайдеры, работающие с Apache предоставляют лог-файлы в общем формате. Это означает то, что они не будут соджержать поля с ссылающимися страницами и юзер-агентами.
Однако, относительно запросов к файлу «robots.txt», предпочтительно иметь доступ ко всем этим данным, чтобы иметь больше информации о посещении поисковиков, чем просто знать их IP адреса. Для того, чтобы оганизовать это, в «.htaccess» должны быть следующие записи:
Теперь при запросе файла «robots.txt» наш RewriteRule переадресует посетителя (робота) к обрабатывающему запросы скрипту text.cgi. Кроме того, переменная передается скрипту, которая будет обработана в соответствии с вашими нуждами. «REQUEST_URI» определяет имя запрашиваемого файла. В данном примере это – «robots.txt». Скрипт прочтет содержание «robots.txt» и отправит его web-браузеру или роботу поискового сервера. Таким образом, мы можем считать хиты посетителей и вести свои лог-файлы.
С этой целью, скрипт будет использовать переменные окружения «$ENV {'HTTP_USER_AGENT'}» и т.д. Это обеспечит получение всей требуемой информации. Вот исходный текст для сценария cgi, упомянутого выше (пример взят с сайта http://fantomaster.com):
Загрузите файл с данным содержимым в корневую или в DocumentRoot директорию сервера и установите права доступа у файлу (chmod) 755. Затем, создайте каталог «stats». Более детальное описание о том, как установить скрипт вы можете получить на сайте разработчика.
Если настройки вашего сервера не позволяют исполнять cgi-сценарии в главной директории (DocumentRoot), то попробуйте следующий вариант:
Обратите внимание, что в этом случае, будет необходимо изменить пути в коде скрипта!
Наконец, вот решение задачки, данной в предыдущей части этой публикации:
Если мы пишем в регулярном выражении «^212.37.64» вместо «^212.37.64.» (с точкой в конце), то даст ли это тот же самый эффект, и будут ли исключены те же самые IP адреса?
Регулярное выражение ^212.37.64 удовлетворяет и применимо к следующим строкам:
Следовательно, последняя цифра «4» может сопровождаться любой символьной строкой. Однако, максимальным значением IP является адрес 255.255.255.255 – который подразумевает, что например 212.37.642.12 – неправильный (недопустимый) IP. Единственный допустимый IP в вышеприведенном списке – 212.37.64.12!
В прошлой главе мы познакомились с основами модуля mod_rewrite. В примере, который был рассмотрен, мы использовали конструкцию, которая в буквальном смысле означает следующее: «Если кто-то пытается получить доступ к файлу .htaccess, выдается ошибка, сообщающая, что доступ к файлу запрещен».
Это «правило» глобально, то есть каждый получит указанное сообщение об ошибке. Напомню, что mod_rewrite является модулем, который предоставляет «основанный на правилах механизм динамического изменения запрашиваемых URL-ов».
Мы можем ограничивать «правило» при помощи различных «условий правила». «Правило» будет выполнено только в том случае, если перед ним будет встречен ряд условий.
Синтаксис: условие должно предшествовать правилу!
Возьмем еще один пример (запись в файле .htaccess):
Назначение первых трех записей было подробно разобрано в первой части публикации. Их функция - включение «движка перезаписи», то есть самого модуля.
Последние две строки запрещают доступ поисковому роботу под кодовым названием «EmailSiphon» (имеется ввиду имя юзер-агента). Данный робот является сборщиком почтовых адресов с различных веб страниц.
Проверочная строка – переменная сервера, которая может быть записана в общей форме: «% {ИМЯ_ПЕРЕМЕННОЙ}».
Образец условия – регулярное выражение. Для более полного понимания темы стоит рассмотреть регулярные выражения как класс.
Регулярные выражения – это механизм, позволяющий задать шаблон для строки и осуществить поиск данных, соответствующих этому шаблону в заданном тексте. Кроме того, дополнительные функции по работе с такими выражениями позволяют получить найденные данные в виде массива строк, произвести замену в тексте по шаблону, разбиение строки по шаблону и т.п. Однако главной их функцией, на которой основаны все остальные, является именно функция поиска в тексте данных, соответствующих шаблону (образцу), описанному в синтаксисе регулярных выражений.
Регулярные выражения подобны маленькому, компактному языку программирования со своими правилами.
Например, регулярное выражение:
заменит строку «abc», на строку «xyz» во всем тексте.
Вот краткий обзор наиболее важных элементов с некоторыми примерами:
. (точка) - текст (любой символ)
| - чередование (то есть/abc|def/)
* - квантификатор (разрешено любое число)
^ $ - якоря строки
s - оператор (string1 заменить на string2)
g - модификатор (искать по всему тексту)
Регулярные выражения конструируются с помощью этих элементов и других «обычных» символов. Они не являются отдельным языком, а используются другими средствами, например языками программирования типа Perl или PHP, а также текстовыми редакторами (Emacs).
Если говорить о связи регулярных выражений и модуля mod_rewrite, то они используются в директивах RewriteRule и RewriteCond.
«^» обозначает начало строки. Из этого следует, что UserAgent должен начинаться со строки «EmailSiphon» и ни с чего другого («NewEmailSiphon», например, не работал бы).
Но, поскольку данное регулярное выражение не содержит символ "$" (якорь конца строки), UserAgent мог бы быть, например, «EmailSiphon2».
Последняя строка нашего примера:
определяет, что именно нужно делать, когда робот запросит доступ.
Регулярное выражение «^.*$» означает: «Доступ ко всем файлам запрещен».
Точка «.» в регулярном выражении – мета символ (подстановочный знак), означающий любой случайный символ.
«*» означает то, что строка может встречаться неограниченное количество раз. В этом случае, независимо от имени запрошенного файла, будет выдана ошибка.
«EmailSiphon», конечно, не единственный почтовый сборщик. Другой известный член этого семейства - «ExtractorPro». Допустим мы хотим запретить доступ и этому роботу. В таком случае нам необходимо еще одно условие.
Теперь файл .htaccess будет выглядеть так:
Третий аргумент [OR] (в первой строке RewriteCond) называется «флагом». Существуют два возможных флага:
NC – не учитывать регистр букв.
OR – означает «или следующее условие».
Флажок NC позволяет игнорировать регистр букв в искомом образце. Например:
Эта строка определяет, что и "emailsiphon" и "EmailSiphon" будут признаны как идентичные выражения.
Вы можете использовать сразу несколько флажков, разделяя их запятыми.
Нет никаких ограничений по числу условий. Таким образом, Вы можете блокировать 10, 100, 1000 или более известных почтовых сборщиков. Определение этих 1000 условий – просто вопрос загрузки сервера и прозрачности файла «.htaccess».
В вышеупомянутом примере используется глобальная переменная «HTTP_USER_AGENT». Существуют также другие переменные: REMOTE_HOST, REMOTE_ADDR
Например, если Вы хотите заблокировать паука пришедшего с www.site.ru, Вы можете использовать глобальную переменную «REMOTE_HOST» таким образом:
Если Вы хотите заблокировать определенный IP адрес, условие будет выглядеть так:
В регулярном выражении по проверке точного и полного IP адреса нужно использовать начальные и конечные якоря.
Также можно исключить целый диапазон:
Этот пример показывает, как можно заблокировать диапазон IP адресов с 212.37.64.0 по 212.37.64.255.
А вот маленькая задачка для проверки приобретенных знаний (решение будет дано в следующей части):
Внимание, вопрос!
Если мы пишем в регулярном выражении «^212.37.64» вместо «^212.37.64.» (с точкой в конце), то даст ли это тот же самый эффект, и будут ли исключены те же самые IP адреса?
До сих пор мы использовали простой RewriteRule, который генерирует сообщение об ошибках. В третьей части публикации мы проанализируем, как можно использовать RewriteRule для переадресации посетителей к определенным файлам.
