Набирая адрес в строке браузера, вы получаете на свой компьютер
файлы, которые отображает браузер. Управление тем, какие файлы и как вам
показывать (пересылать) осуществляет веб-сервер. Наиболее популярных серверов
два: IIS и Apache. Как и любая программа, веб-сервер имеет определенные
настройки. Но, у вас, как пользователя Апача может (и скорее всего не будет,
если говорить о виртуальном хостинге) прав менять конфигурацию Апача через его
главные файлы, действие которых распространяется на всех пользователей этого
сервера. Но, вы можете менять некоторые конфигурационные файлы, который
распространяют свое действие только на ваш сайт. Один из таких файлов -
.htaccess Это файл гибкой настройки веб-сервера Апач. "Гибкий" обозначает,
что как только вы поменяли что-то в этом файле, изменения тут же вступают в
силу. С помощью него можно переопределить многие директивы из файла httpd.conf
(этот файл является главным конфигурационным файлом сервера Апач и его действия
распространяются полностью на всех пользователей данной копии Апача). В случаях,
когда у вас нет доступа в файлу настройки Апача (тот же виртуальный хостинг),
вам поможет именно этот файл. Этот файл не доступен веб-пользователю из
браузера. Если файл .htaccess расположен в корневой директории сервера, то его
действия распространяется на весь сервер, кроме тех папок, где находится другой
файл .htaccess (и кроме всех папок "ниже" этой папки со вторым
.htaccess). Пример: Структура ваших директорий на сервере такая:
Директории user1 и user2 будут вложенными по отношению к
директории user. Если мы поместим в директорию www файл .htaccess, то его
действие будет автоматически распространяться и на директории user1 и
user2. В директорию data помещаем другой файл .htaccess, по-сравнению, с тем,
что находится в директории user. И для директорий data1 и data2 будет
действовать файл .htacсess, находящийся в data. Теперь, в директорию user2 мы
помещаем еще один файл .htaccess, который отличен от того, что находится в
директории 2мя уровнями выше (это директория user). В итоге, настройки для
директории user2 будут определяться только тем файлом .htaccess, который
находится в этой директории. Так как чаще всего Апач настроен так, что всегда
ищет этот файл в директории, то .htaccess поможет вам быстро и без останова
сервера произвести его перенастройку.
Вот обязательной синтаксис, несоблюдение которого приводит к
ошибкам сервера: - пути к файлам (директориям) указываются от корня сервера.
Пример: /opt/home/www.astanafoto.com/htdocs/config/.htpasswords - домены с
указанием протокола Пример: Redirect / http://www.site.ru
Файл имеет
название именно "точка" htaccess Должен быть записан в UNIX-формате. Для
оболочки FAR, достигается F4 (редактирование файла), Shift+F2 (выбрать
"сохранить как UNIX-текст").
Как запретить веб-посетителям читать файлы в
директории?
Запрет на все файлы: deny from
all Где all обозначает "все".
Разрешить доступ с определенного
ip: order allow deny deny from all allow from <ваш
ip>
В данном случае, <ваш ip> обозначает
конкретный адрес. Например: order allow deny deny from
all allow from 192.126.12.199
Запретить доступ с определенного
ip: order allow deny deny from all deny from <ваш
ip>
Использование <ваш ip> аналогично для примера
выше.
Запрет на группу файлов по
маске: <Files ".(inc|sql|...другие
расширения...)$"> order allow,deny deny from
all </Files>
Определяет доступ к файлу по его
расширению. Например запрет на доступ к файлам с расширениям "inc" для
веб-посетителей: <Files ".(inc)$"> order allow,deny deny from
all </Files>
В данном примере сам веб-сервер Апач может
обращаться к файлам с таким расширениям.
Запрет на конкретный файл: Можно
поставить запрет на конкретный файл по его названию и
расширению. <Files config.inc.php> order allow,deny deny
from all </Files>
В данном примере стоит запрет на
обращения к файлу config.inc.php.
Значение AuthName будет выводиться
для посетителя и может использоваться для пояснения запроса авторизации.
Значение AuthUserFile указывает на место, где хранится файл с паролями для
доступа к данной директории. Этот файл создается специальной утилитой
htpasswd.exe.
Например в директории, которую защищаем паролем создаем
такой .htaccess: AuthName "For Registered Users Only" AuthType
Basic AuthUserFile /pub/site.ru/.htpasswd require
valid-user </Files>
В этом примере, посетитель при
запросе директории, будет читать фразу "For Registered Users Only", файл с
паролями для доступа должен лежать в директории /pub/site.ru/ и называться
.htapasswd . Директория указывается от корня сервера, если вы неправильно
зададите директорию, то Апач не сможет прочитать файл .htpasswd и никто не
получит доступа к данной директории.
Пароль только на 1 файл: Аналогично
паролированию директории полностью, можно ставить пароль только на 1
файл. Пример установки пароля на файл private.zip: <Files
private.zip> AuthName "Users zone" AuthType Basic AuthUserFile
/pub/home/твой_логин/.htpasswd </Files>
Пароль на группу файлов: Аналогично,
используя <Files ".(inc|sql|...другие расширения...)$">, можно ставить
пароли по маске файлов. Пример установки пароля на доступ ко всем файла с
расширением "sql": <Files ".(sql)$"> AuthName "Users
zone" AuthType Basic AuthUserFile
/pub/home/твой_логин/.htpasswd </Files>
Задача: есть каталог a1 и в нем два вложенных каталога a2,
a3, введено 2 уровня пользователей. 1 группа имеет доступ только к a1 и a2, 2-я
ко всем трем каталогам. Необходимо проводить аутентификацию только 1 раз - при
доступе к a1, но при этом соблюдать права на доступ к а2 и а3. Ник и пароль
запрашиваются только при входе на а1 - если у юзвера есть доступ на а2 пароль
уже не запрашивается. Если на а3 доступа нет, вылетит табличка "введите
пароль".
www.site.ru/a1 www.site.ru/a1/а2 www.site.ru/a1/a3 a1 -
общий и вместе с тем закрытый. а2 и а3 только для отдельных личностей.
файл .htaccess для каталога а1: AuthName "Input
password" AuthType Basic AuthUserFile
"/pub/home/login/htdocs/clousearea/.htpasswd" <Files *.*> require
valid-user </Files>
файл .htaccess для каталога
а2: AuthName "Input password" AuthType Basic AuthUserFile
"/pub/home/login/htdocs/clousearea/.htpasswd" <Files *.*> require
user юзвер1 юзвер2 юзвер3 </Files *.*>
файл .htaccess для
каталога а3: AuthName "Input password" AuthType
Basic AuthUserFile "/pub/home/абв/htdocs/clousearea/.htpasswd" <Files
*.*> require user юзвер1 юзвер4 юзвер5 </Files *.*>
Как сделать перенаправление (редирект) посетителя?
Редирект на другой url: Что бы сделать
перенаправления посетителя на сайт http://site.ru в .htaccess Redirect /
http://www.site.ru
Показ разных страниц, в зависимости от IP
адреса посетителя: SetEnvIf REMOTE_ADDR <нужный ip адрес>
REDIR="redir" RewriteCond %{REDIR} redir RewriteRule ^/$
/another_page.html
Например, перенаправление посетителей с ip
адресом 192.12.131.1 на страницу about_my_sity.html: SetEnvIf
REMOTE_ADDR 192.12.131.1 REDIR="redir" RewriteCond %{REDIR}
redir RewriteRule ^/$ /about_my_sity.html
Перенаправление посетителя при запросе
определенных страниц: Это уже для всех сетевых вирусов и сканеров. Теперь
любой запрос с адресом /_vti_bin будет автоматически перенаправляться на
Microsoft:
SSI позволяют "собирать" страницу из кусочков. В одном кусочке у
вас код меню, в другом код верхней части страницы, в третьем - нижней. А
посетитель видет обычную страницу, которая состоит из того кода, который входит
в ваши кусочки. Необходимы обязательные установки в httpd.conf: В
блоке, начинающемся с <Directory/> и заканчивающийся </Directory> в
строку Options Indexes добавьте Includes.
Как заставить Апач выполнять в html документах php
код?
Иногда бывает полезно "обмануть" посетителя, выдавая ему свои
php-скрипты или иные файлы, как html файлы. Реально используется для индексации
поисковой системой Rambler php-скриптов. Некоторые делаю мелкие фишки, вроде
того, что дают фалам расширения совпадающие с какими-либо "знаковыми" именами.
Например, на сайте www.osg.ru используются
файлы с расширением osg: index.osg, script.osg и т.п.
Наиболее интересные и полезные ошибки Апача это: 403-404,
500. 403 - пользователь не прошел аутентификацию, запрет на доступ
(Forbided). 404 - запрашиваемый документ (файл, директория) не найден. 500
- внутренняя ошибка сервера (к примеру, ошибка в синтаксисе файла
.htaccess). Для того, что бы пользователю при этих ошибках были показаны ваши
собственные сообщения об ошибках, в .htaccess пишем:
При этом при возникновении 404 ошибки
пользователю загрузится файл errors/403.html.
Удобно делать собственный обработчик на некоторые ошибки. В
.htaccess пишем: ErrorDocument 403
/errors/error.php?403 ErrorDocument 404
/errors/error.php?404 ErrorDocument 500 /errors/error.php?500
В
error.php через $HTTP_SERVER_VARS['REQUEST_URI'] определяем какой документ
вызвал ошибку и дальше обрабатываем. Если в .htaccess на ErrorDocument стоит
указание файла с полным путем (http://site.ru/error.php), то
$HTTP_SERVER_VARS['REQUEST_URI'] будет содержать этот файл, а не вызвавший
ошибку. В Internet Explorer 5.0 неправильно обрабатывается файл, вызывающийся
при ошибке, если его размер меньше 1 килобайта. Будет вызвана стандартная
страница IE 404.
Как поставить запрет на отображение содержимого
директории при отсутствии индексного файла?
Предположим, что у вас вся графика, используемая на сайте
находится в директории img. Посетитель может набрать в адресной строке браузера
эту директорию и увидеть список всех ваших графических файлов. Конечно, это не
нанесет вам урона, но можно и не дать такого просмотра посетителю. В .htaccess
пишем:
Можно ли указать кодировку на все файлы, в которой
по умолчанию получает документы браузер?
На заре интернета и зарождения браузеров, часто была ситуация, что
браузер не мог автоматически определить, в какой из русских кодировок написан
документ и в браузер выдавалась какая-то каша. Для избежания этого указываем,
что все отдаваемые страницы будут иметь кодировку
windows-1251:
При разработке CMS S.Builder наша команда
активно использовала AJAX. Теперь вот решили поделиться накопленным
опытом. Начнем с этого хабратопика. Не буду здесь затрагивать различные
фреймворки и библиотеки. Свой код всегда роднее. Для работы с AJAX-ом в
S.Builder написана библиотека
sbAJAX. Можете качать и пользоваться :). В этом файле есть функция
sbEvalJS. Для тех, кто не знает, объясню. При подгрузке через AJAX и вставке
на страницу HTML-кода, содержащего JavaScript, JavaScript выполняться не будет
или полезут баги. Эта функция как раз решает поставленную задачу.
Хотя наш обзор немного запоздал, оригинальный Dojo 1.2 вышел в релизной
версии ещё 6-го октября, но сейчас мы наверстаем упущенное. И так, Dojo Toolkit — это самая мощная и
гибкая ajax-библиотека из всех, что есть на рынке, она активно развивается и
имеет большое комьюнити. Кстати, это самое комьюнити, совместно с компанией
Sitepen, имеет ещё несколько проектов, среди которых и Cometd и некоторые
другие, не менее интересные, о которых мы скоро вам расскажем. Сегодня же все
внимание на флагманский продукт —
Dojo
1.2.
Если вы профессиональный веб-разработчик и постоянно имеете дело с
разработкой и отладкой сложных AJAX приложений, то наверняка знаете и
используете Firebug — плагин для браузера
Firefox, предназначенный для отладки и исследования веб-приложений. Текущая его
версия, 1.2х достаточно стабильная и функциональна, чтобы помочь в 99% проблем,
которые могут возникнуть при разработке. Но и этот инструмент не лишён если не
недостатков, то некоторых фич, которые могли бы облегчить работу. И даже
идеальный инструмент можно сделать ещё более идеальным, как бы это не звучало.