Вы наверняка встречали в сети термин 'mod_rewrite'. Для наших
читателей, которые не до конца знакомы с этим модулем веб сервера
Apache, а также для тех, кто вообще первый раз об этом слышит -
постараюсь рассказать в этой публикации (в нескольких частях)
подробнее о данном модуле.
Модуль mod_rewrite является программным модулем веб сервера Apache
(обратите внимание, что он не будет выполняться под другими веб
серверами!). Его первичная функция - манипуляция действий с URL.
Модуль очень универсален и разносторонен, поэтому я постараюсь
показать здесь множество реальных примеров.
Mod_rewrite является замечательным модулем, который предоставляет
'основанный на правилах механизм динамического изменения запрашиваемых
URL-ов'. Это действительно мощный инструмент, и поэтому, его знание
принципиально важно, если вы хотите стать подлинным веб мастером или
веб программистом. Не столько принципиально, будете ли вы использовать
его в своей работе, сколько важно то, что вы знаете, что он может
делать, и сможете поведать об этом своему боссу, когда появится
желание сделать что-нибудь странное с веб сервером.
Однако нужно быть очень осторожным и даже дотошным при работе с этим
модулем! Некоторые ошибки, которые Вы способны допустить, могут
привести к логической петле, причиняя непрекращающуюся 100%-ую
загрузку ценрального процессора (CPU).
Чтобы не казаться пространным в рассуждениях, приведу некоторые очень
простые примеры.
Прежде, чем мы сможем приступить к работе, Вы должны будете проверить,
установлен ли модуль на вашем веб сервере или нет.
Есть несколько способов проверить это:
1. Спросить вашего системного администратора - знает ли он (или она)
о наличии этого модуля на веб сервере. Они действительно должны
знать, но как показывает практика - попадаются и не очень
сведующие сисадмины ...
Не напрягайте других: если Вы используете ваш веб сервер с сотнями
других доменов, ваши действия могут разбудить некоторых спящих
собак, поскольку использование mod_rewrite будет всегда влечь за
собой некоторую увеличенную загрузку ценрального процессора.
2. Проверить ваш файл конфигурации Apache (httpd.conf), если Вы
имеете к нему доступ. Один из возможных стандартных путей может
быть:
/etc/httpd/httpd.conf
Однако, ваш путь может очевидно отличаться от этого.
3. Проверить работу вашего сервера с нижеприведенными примерами. Если
сервер работает без ошибок - mod_rewrite действительно установлен
на вашей системе. Если нет, Вы получите следующее сообщение при
запросе любой web-страницы с вашего сервера: 'Внутренняя ошибка
сервера'
Также, Вы увидите такую запись в файле 'error.log':
'Invalid command 'RewriteEngine', perhaps mis-spelled or defined by a
module not included in the server configuration'.
Теперь давайте копнем поглубже и посмотрим первый практический
примерчик.
Предположим, что Вы будете использовать mod_rewrite только для вашего
собственного сайта, то есть не как обобщенную перекрестную установку
сервера.
Для нашего примера потребуется использование файла .htaccess.
файл .htaccess
Для работы этого метода, Вы должны загрузить файл под названием
'.htaccess' (пожалуйста, обратите внимание на точку в начале имени
файла!) в папку сервера, с которой Вы будете работать. Это можно
сделать через telnet или ftp. (Предупреждение: .htaccess должен быть
загружен в 'режиме ASCII', то есть не в бинарном режиме!)
Если у Вас уже имеется файл '.htaccess', например со следующими
записями:
Options Includes +ExecCGI
AddType text/x-server-parsed-html .html
то просто добавьте снизу наш образец кода к уже существующему (Важно:
редактируйте ваш файл .htaccess в ASCII-редакторе типа Notepad).
Первые две записи запустят сам модуль:
RewriteEngine on
Options +FollowSymlinks
Совет: запись 'RewriteEngine off' отменит все последующие команды. Это
- очень полезная особенность: вместо необходимости комментировать все
последующие строки - все, что Вы должны сделать, это установить 'off'.
Если ваш системный администратор запрещает Вам использование 'Options
+FollowSymlinks', Вы не сможете ограничить использование mod_rewrite
для отдельных каталогов, вместо этого изменения будут действовать на
весь сервер.
Следующая необходимая запись - это:
RewriteBase /
'/' является корневым (основным) URL. Если у Вас какой-то другой URL,
Вы можете указать это в данной директиве, однако '/' - обычно
эквивалентно адресу 'http://домен.ру'.
А теперь, господа, перейдем к более интересным записям!
Предположим, что вы хотите защитить от несанкционированного доступа
ваш файл .htaccess. На некоторых серверах Вы можете легко читать этот
файл просто вводя URL следующего формата в поле адреса вашего
браузера: http://www.domain.com/.htaccess - серьезное упущение защиты,
так как содержание вашего .htaccess может показать важную информацию
об установках и настройках вашего сайта человеку, знающему как эти
знания применить против вас.
Чтобы блокировать этот доступ, запишем следующее:
RewriteRule ^.htaccess$ - [F]
Это правило переводится так:
Если кто-то пробует обращаться к файлу .htaccess, система должна
произвести код ошибки 'HTTP response of 403' или '403 Forbidden - You
don't have permission to access /.htaccess on this server'.
Конструкция ^.htaccess$ в этом регулярном выражении означает:
^ - якорь начала строки
$ - якорь конца строки
. - в регулярных выражениях точка '.' обозначает мета-символ и должна
быть защищена обратным слэшем (backslash), если Вы все-таки хотите
использовать именно фактическую точку.
Имя файла должно быть расположено точно между начальным и конечным
якорем. Это будет гарантировать то, что только это определенное имя
файла и никакое другое, сгенерирует код ошибки.
[F] - специальный 'запрещающий' флажок (forbidden).
В этом примере, файл ".htaccess" теперь будет состоять из таких строк:
RewriteEngine on
Options +FollowSymlinks
RewriteBase /
RewriteRule ^.htaccess$ - [F]
Если мы добавим наш код (в примерах) к существовавшему ранее файлу
'.htaccess', то получим следующую конструкцию:
Options Includes +ExecCGI
AddType text/x-server-parsed-html .html
RewriteEngine on
Options +FollowSymlinks
RewriteBase /
RewriteRule ^.htaccess$ - [F]
Это введение затрагивает лишь основы, требуемые для того, чтобы
работать с модулем mod_rewrite. Во второй части этой обучающей серии
статей постараюсь объяснить использование различных условий в
конфигурировании модуля.
Ссылки по теме:
http://www.apache.org/docs/mod/mod_rewrite.html
Модуль mod_rewrite. Часть 2.
В прошлой главе мы познакомились с основами модуля mod_rewrite. В
примере, который был рассмотрен, мы использовали конструкцию, которая
в буквальном смысле означает следующее: 'Если кто-то пытается получить
доступ к файлу .htaccess, выдается ошибка, сообщающая, что доступ к
файлу запрещен'.
Это 'правило' глобально, то есть каждый получит указанное сообщение об
ошибке. Напомню, что mod_rewrite является модулем, который
предоставляет 'основанный на правилах механизм динамического изменения
запрашиваемых URL-ов'.
Мы можем ограничивать 'правило' при помощи различных 'условий
правила'. 'Правило' будет выполнено только в том случае, если перед
ним будет встречен ряд условий.
Синтаксис: условие должно предшествовать правилу!
Возьмем еще один пример (запись в файле .htaccess):
Назначение первых трех записей было подробно разобрано в первой части
публикации. Их функция - включение 'движка перезаписи', то есть самого
модуля.
Последние две строки запрещают доступ поисковому роботу под кодовым
названием 'EmailSiphon' (имеется ввиду имя юзер-агента). Данный робот
является сборщиком почтовых адресов с различных веб страниц.
Проверочная строка - переменная сервера, которая может быть записана в
общей форме: '% {ИМЯ_ПЕРЕМЕННОЙ}'.
Образец условия - регулярное выражение. Для более полного понимания
темы стоит рассмотреть регулярные выражения как класс.
Регулярные выражения
Регулярные выражения - это механизм, позволяющий задать шаблон для
строки и осуществить поиск данных, соответствующих этому шаблону в
заданном тексте. Кроме того, дополнительные функции по работе с такими
выражениями позволяют получить найденные данные в виде массива строк,
произвести замену в тексте по шаблону, разбиение строки по шаблону и
т.п. Однако главной их функцией, на которой основаны все остальные,
является именно функция поиска в тексте данных, соответствующих
шаблону (образцу), описанному в синтаксисе регулярных выражений.
Регулярные выражения подобны маленькому, компактному языку
программирования со своими правилами.
Например, регулярное выражение:
s/abc/xyz/g
заменит строку 'abc', на строку 'xyz' во всем тексте.
Вот краткий обзор наиболее важных элементов с некоторыми примерами:
. (точка) - текст (любой символ)
| - чередование (то есть/abc|def/)
* - квантификатор (разрешено любое число)
^ $ - якоря строки
s - оператор (string1 заменить на string2)
g - модификатор (искать по всему тексту)
Регулярные выражения конструируются с помощью этих элементов и других
'обычных' символов. Они не являются отдельным языком, а используются
другими средствами, например языками программирования типа Perl
или PHP, а также текстовыми редакторами (Emacs).
Если говорить о связи регулярных выражений и модуля mod_rewrite, то
они используются в директивах RewriteRule и RewriteCond.
'^' обозначает начало строки. Из этого следует, что UserAgent должен
начинаться со строки 'EmailSiphon' и ни с чего другого
('NewEmailSiphon', например, не работал бы).
Но, поскольку данное регулярное выражение не содержит символ "$"
(якорь конца строки), UserAgent мог бы быть, например, 'EmailSiphon2'.
Последняя строка нашего примера:
RewriteRule ^.*$ - [F]
определяет, что именно нужно делать, когда робот запросит доступ.
Регулярное выражение '^.*$' означает: 'Доступ ко всем файлам
запрещен'.
Точка '.' в регулярном выражении - мета символ (подстановочный знак),
означающий любой случайный символ.
'*' означает то, что строка может встречаться неограниченное
количество раз. В этом случае, независимо от имени запрошенного файла,
будет выдана ошибка.
'EmailSiphon', конечно, не единственный почтовый сборщик. Другой
известный член этого семейства - 'ExtractorPro'. Допустим мы хотим
запретить доступ и этому роботу. В таком случае нам необходимо еще
одно условие.
Нет никаких ограничений по числу условий. Таким образом, Вы можете
блокировать 10, 100, 1000 или более известных почтовых сборщиков.
Определение этих 1000 условий - просто вопрос загрузки сервера и
прозрачности файла '.htaccess'.
В вышеупомянутом примере используется глобальная переменная
'HTTP_USER_AGENT'. Существуют также другие переменные:
REMOTE_HOST
REMOTE_ADDR
Например, если Вы хотите заблокировать паука пришедшего с www.site.ru,
Вы можете использовать глобальную переменную 'REMOTE_HOST' таким
образом:
Если мы пишем в регулярном выражении '^212.37.64' вместо '^212.37.64.'
(с точкой в конце), то даст ли это тот же самый эффект, и будут ли
исключены те же самые IP адреса?
До сих пор мы использовали простой RewriteRule, который генерирует
сообщение об ошибках. В третьей части публикации мы проанализируем,
как можно использовать RewriteRule для переадресации посетителей к
определенным файлам.
Модуль mod_rewrite. Часть 3.
В двух предыдущих частях мы познакомились с основами 'правил
перезаписи' 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:
RewriteEngine on
Options +FollowSymlinks
RewriteBase /
RewriteRule ^(.*)shop/(.*)$ $1cgi-bin/shop.cgi?$2
Переменные $1 и $2 составляют так называемые "backreferences". Они
связаны с текстовыми группами. Вызываемый URL разбивается на части.
Все, что находится перед 'shop', плюс все что находится после 'shop/'
определяется и хранится в этих двух переменных: $1 и $2.
До этого момента, наши примеры использовали 'правила' типа:
RewriteRule ^.htaccess*$ - [F]
Однако мы еще не достигли истинной перезаписи URL адресов, в смысле
того, что один URL должен перенаправлять посетителя на другой.
Для нашей записи вида:
RewriteRule ^(.*)shop/(.*)$ $1cgi-bin/shop.cgi?$2
применяется общий синтаксис:
RewriteRule текущийURL перезаписываемыйURL
Как видите, эта директива выполняет действительную 'перезапись' URL
адреса.
В дополнение к записям в файл .htaccess, нужно еще заменить все ссылки
на сайте, которые имеют формат 'cgi-bin/shop.cgi?product', на ссылки
вида: 'shop/product'
Теперь, когда поисковик найдет страницу с подобными ссылками, он
проиндексирует сайт без всяких видимых проблем.
Таким образом вы можете превратить чисто динамический сайт в сайт,
имеющий статическую структуру, что явно принесет пользу в вопросе
индексирования различными посковыми машинами. Обратите внимание на вид
URL адресов на данном сайте. Вдобавок ко всему, они имеют еще и
легкочитамую для человека структуру - ЧПУ (человекопонятный УРЛ). Но
об этом мы поговорим в другой статье.
В нашем втором примере мы обсудим, как переадресовать запросы '.txt'
файлов к сценарию программы.
Многие хостинг провайдеры, работающие с Apache предоставляют лог-файлы
в общем формате. Это означает то, что они не будут соджержать поля с
ссылающимися страницами и юзер-агентами.
Однако, относительно запросов к файлу 'robots.txt', предпочтительно
иметь доступ ко всем этим данным, чтобы иметь больше информации о
посещении поисковиков, чем просто знать их IP адреса. Для того, чтобы
оганизовать это, в '.htaccess' должны быть следующие записи:
RewriteEngine on
Options +FollowSymlinks
RewriteBase /
RewriteRule ^robots.txt$ /text.cgi?%{REQUEST_URI}
Теперь при запросе файла 'robots.txt' наш RewriteRule переадресует
посетителя (робота) к обрабатывающему запросы скрипту text.cgi. Кроме
того, переменная передается скрипту, которая будет обработана в
соответствии с вашими нуждами. 'REQUEST_URI' определяет имя
запрашиваемого файла. В данном примере это - 'robots.txt'. Скрипт
прочтет содержание 'robots.txt' и отправит его web-браузеру или роботу
поискового сервера. Таким образом, мы можем считать хиты посетителей и
вести свои лог-файлы.
С этой целью, скрипт будет использовать переменные окружения '$ENV
{'HTTP_USER_AGENT'}' и т.д. Это обеспечит получение всей требуемой
информации. Вот исходный текст для сценария cgi, упомянутого выше
(пример взят с сайта http://fantomaster.com):
#!/usr/bin/perl
# If required, adjust line above to point to Perl 5.
#################################
# (c) Copyright 2000 by fantomaster.com #
# All rights reserved. #
#################################
sub log_hits {
open (HITS, ">>$stats_dir/$log_file");
print HITS @_;
close (HITS);
}
Загрузите файл с данным содержимым в корневую или в DocumentRoot
директорию сервера и установите [18]права доступа у файлу (chmod) 755.
Затем, создайте каталог 'stats'. Более детальное описание о том, как
установить скрипт вы можете получить [19]на сайте разработчика.
Если настройки вашего сервера не позволяют исполнять 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. Часть 4.
В этой публикации мы затронем те директивы, которые не успели охватить
в предыдущих частях. Эти директивы не поддаются определению на уровне
директорий. Это означает то, что вы должны иметь доступ к файлу
конфигурации веб сервера Apache (httpd.conf).
Обычно такой доступ имеют пользователи 'root' или администратор
сервера.
Если вы хотите вести логи всех операций, выполненных с помощью
mod_rewrite, можно активировать это с помощью следующей записи:
Эту строку нужно вписать в 'Раздел 2: Конфигурация основного сервера'
в файле httpd.conf, а не в .htaccess!
Все манипуляции, произведенные mod_rewrite будут записываться в этот
файл. Имя лог файла может быть любым. Вы можете указать абсолютный или
относительный (относительно ServerRoot) путь к файлу.
Если вы хотите вести разные лог файлы для различных виртуальных
хостов, то нужно ввести изменения в 'Раздел 3: Виртуальные сервера',
например так:
RewriteLogLevel может быть определен в пределах диапазона от 1 до 8.
Обычно достаточно первого уровня. Более высокие уровни используются
для деббагинга.
Другая директива, которая является очень удобной в целях клоакинга -
это так называемая карта перезаписи. Это - файлы, содержащие пары
ключ/значение, обычно в формате текстового файла:
Ключи, как вы видите, имена хостов или IP адреса. В этом простеньком
примере значение всегда одно - 'spider'. Естественно, в реальном файле
значения будут другие. Эта директива может быть записана в второй
('Конфигурация основного сервера') или третий ('Виртуальные сервера')
раздел файла httpd.conf:
Данные условия будут производить системную проверку: произведен ли
запрос поисковиком. С этой целью производится поиск по файлу
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 одну единственную строку:
pic-08-28.html
pic-08-29.html
pic-08-30.html
и так далее.
Теперь, все что вы должны сделать - это единожды загрузить файлы с
соответсвующими именами и забыть о ежедневном обновлении ссылки.
Переменные времени также могут использоваться для другой
периодичности.
Это был последний пример в серии публикаций о замечательном модуле
mod_rewrite. Естественно невозможно было затронуть все нюансы,
директивы, переменные и т.д. в данной публикации, целью было другое -
дать общее представление и понимание основ, и так сказать 'ввести в
курс дела'.
Vova
