Закрываем доступ к сайту с помощью .htaccess и PHP
В этой статье я хочу исправить одну из моих ошибок, точнее не совсем ошибку, просто не очень удачный совет.
Дело в том, что недавно я просматривал собственные посты и заметил, что в одном из них задача решается далеко не лучшим образом. Речь шла о блокировке доступа к блогу на движке WordPress.
Решение, которое я тогда предложил, работоспособное и им вполне можно пользоваться. Но только какое-то оно сложное 
Нужно было использовать несколько файлов .htaccess для разных папок блога. Доступ для администратора получался немного ограниченным, например, статические ссылки не работали.
И, самое главное. Как абсолютно верно заметил Олег Лобач в комментариях к тому посту, если сайт закрыт на обслуживание, то необходимо отправлять заголовок с 503 кодом (Service Unavailable).
Для посетителей этот код роли не играет, они все равно увидят страницу с описанием ошибки, но вот поисковые боты – другое дело. Думаю, никому не захочется, чтобы в индекс поисковика попала фраза «Зайдите позже» вместо контента блога.
В общем, сейчас хочу рассказать о другом, на мой взгляд, более удачном решении.
Нужно будет выполнить всего два шага.
1) Создать страницу, которую будем показывать посетителям во время обслуживания сайта.
2) Добавить пару строк в файл .htaccess, который находится в корне блога.
Кстати, этот метод подойдет практически для любого сайта не зависимо от используемого движка.
Идея заключается в ограничении доступа на основании IP адреса. Т.е. при попытке доступа к сайту web сервер (apache) проверит ваш IP и если он не совпадет с заданным, то все запросы будут перенаправлены на специальную страницу.
Итак, приступим.
Шаг 1. Создаем страницу с сообщением о том, что сайт временно закрыт.
Назовем её maintain.php и разместим в корне сайта.
-
<?php
-
header('HTTP/1.0 503 Service Unavailable');
-
header('Retry-After: 3600');
-
?>
-
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-
<html xmlns="http://www.w3.org/1999/xhtml">
-
<head>
-
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
-
<title>Обслуживание сайта</title>
-
</head>
-
<body>
-
<h1>Извините, в данный момент сайт закрыт на обслуживание</h1>
-
<p>Зайдите немного позже</p>
-
</body>
-
</html>
Обсуждать тут особенно нечего. Саму страницу, конечно, лучше оформить в соответствии с общим дизайном сайта.
Но сейчас важнее заголовки (строки 2 и 3). Для их отправки используется стандартная функция PHP – header. В её первом параметре указываем заголовок.
Первый заголовок отправляет 503 HTTP код, а второй (Retry-After) – время, через которое рекомендуется обновить страницу. В данном примере я установил 1 час (3600 сек), но вы можете выбрать любой интервал времени по своему усмотрению.
Шаг 2. Определяем собственный IP.
Тут ситуация следующая. Если у вас статический IP адрес, то вы его знаете и определять ничего не надо 
Но большинство интернет провайдеров просит за него дополнительные деньги. И если вы эту услугу не заказывали, то при подключении IP адрес будет выдаваться вам каждый раз новый (на практике он меняется довольно редко).
Поэтому заходим на эту страницу и переписываем свой текущий IP-шник.
Шаг 3. Делаем резервную копию файла .htaccess.
Например, с названием .htaccess_main.
Шаг 4. Добавляем проверку IP.
В качестве примера, рассмотрим .htaccess, который часто используется в блогах на WordPress.
-
<IfModule mod_rewrite.c>
-
RewriteEngine On
-
RewriteBase /
-
-
RewriteCond %{REQUEST_FILENAME} !-f
-
RewriteCond %{REQUEST_FILENAME} !-d
-
RewriteRule . /index.php [L]
-
</IfModule>
Примечание. Правила в этом файле подходят для любого движка, в котором запросы обрабатываются скриптом index.php. Например, для сайтов, использующих фреймворк CodeIgniter такой .htaccess тоже вполне подойдет.
Добавляем две дерективы после RewriteBase /
-
RewriteCond %{REMOTE_ADDR} !=127.0.0.2
-
RewriteRule ^.* maintain.php [L]
Т.е. в результате получится.
-
<IfModule mod_rewrite.c>
-
RewriteEngine On
-
RewriteBase /
-
-
RewriteCond %{REMOTE_ADDR} !=127.0.0.1
-
RewriteRule ^.* maintain.php [L]
-
-
RewriteCond %{REQUEST_FILENAME} !-f
-
RewriteCond %{REQUEST_FILENAME} !-d
-
RewriteRule . /index.php [L]
-
</IfModule>
Естественно, вместо 127.0.0.1 нужно указать свой реальный IP адрес.
Принцип работы предельно простой. В директиве RewriteCond (строка 5) мы сравниваем IP адрес посетителя с указанным. И если они не совпадают – отправляем посетителя на maintain.php (строка 6). Буква L в квадратных скобках указывает, что если это правило выполнилось, то обработку запроса нужно прекратить. Т.е. все последующие строки будут проигнорированы.
Если же вы сами заходите на сайт (IP-шники совпадают), то директива RewriteRule (в строке 6) пропускается и web сервер обрабатывает запрос как обычно.
Шаг 5. Восстанавливаем доступ к сайту.
Для этого просто восстанавливаем старый .htaccess файл из резервной копии.
Небольшое дополнение.
Если в процессе работы у вас изменится IP адрес, то вам нужно повторить шаг 2, создать .htaccess с новым IP и скопировать его в корень сайта по FTP.
Вот и все!
Все вопросы и замечания оставляйте в комментариях. Буду рад ответить или обсудить
До встречи!
Интересно почитать
Штукатурка кирпича по пеноблокам – достаточно сложная операция… но только не для профессионалов!
Узнать все объявления белоруссии вы сможете с помощью нашего сайта.
Понравилась статья? Подписывайтесь на продолжение 
!
Или на мой твиттер 
Добавьте эту страницу в 
Опубликовано в PHP, Web разработка, htaccess Комментарии (17) »
Комментарии (17)
Вы можете отслеживать обсуждение записи с помощью RSS 2.0
Вы также можете оставить комментарий, или трекбек с Вашего сайта.
А можно просто поставить плагин
k0ev, конечно же можно. Но я думаю, что гораздо интереснее и полезнее всётаки знать как это работает.
Спасибо!
Отличный пост. Как раз ломал голову над подобной проблеммой.
Честно говоря, я не уверен, что с этим плагином будет проще. Особенно, если вы захотите переделать оформление под свой блог.
В принципе, ничего сложного, но придется покопаться в файлах плагина. Отдельную страничку быстрее сделаете.
А переписывание файла htaccess по FTP занимает не больше времени чем вход в админку и активация плагина.
Выбирать, конечно, вам, но вряд ли вы выиграете много времени за счет этого плагина
Я полностью согласен с тем что знать как работает полезно и нужно.
Но плагин и генерирует 503 ошибку, и позволяет админу управлять сайтом и иметь доступ к UI пока сайт закрыт. Ну и естественно позволяет редактировать страницу с сообщением под любой дизайн.
Ну и в конце концов согласитесь что проще поставить галочку
Согласен, галочку поставить проще
Но есть момент, который я упустил. В инструкции по одному из обновлений (по моему это был переход с версий 2.3 на 2.5, не помню точно) рекомендовалось сначала удалить все старые файлы движка, а потом записать новые (при обычном обновлении файлы записываются поверху).
Я не разбирался с принципом работы Maintenance Mode, но рассчитывать на работу плагина при таком обновлении я бы не рискнул
а можно что-то типа такого дописать:
### SERVER on maintenance ###RewriteCond %{DOCUMENT_ROOT}/maintenance.html -f
RewriteRule ^.*$ /maintenance.html [L]
и положить в корень файл !maintenance.html, а во время проведения работ переименовывать его в maintenance.html …
Отличное решение!
Только проверка IP все равно нужна…
В код закралась опечатка: извените нужно через И.
Спасибо огромное!
Уже исправил.
Хорошее решение.
Либо реализовать через куки ("админские куки"
, тогда решается вопрос с динамическим айпишником
С куками удобнее, но нужно следить чтобы их никто не увёл
Вот с куками интереснее. Может сделаете примерчик как отслеживать по кукам?
Нет, такой пример делать не буду. На мой взгляд, это не очень безопасно.
Какой бред! – только и всего, сказали веб-разработчики и дизайнеры, сидящие рядом в комнате, в ответ я тихо промолчал. Зачем вообще закрывать сайт, даже на время? Это пережитки прошлого века. Соответственно никаких отвертки и пассатижи на первой странице сайта – не нужны. Делайте всё так, чтобы сайт не закрывать и пользователи продолжали на него заходить. Благо на дворе 2010 год и все программные средства для этого имеются.
Дело не в программных средствах. Дело в собственных ошибках и недоработках, которые потом приходится исправлять, а для этого на время нужно ограничить доступ к сайту. Иногда нужно просто расширить функционал.