wp.aspekti.eu

Защита сайта с помощью .htaccess и .htpasswd

В данной статье будет рассмотрен самый простой и доступный способ защиты — базовая аутентификация.

Замечание

Аутентификация — процесс, с помощью которого проверяется, что некто является именно тем, за кого он себя выдает. Как правило, проверка включает в себя ввод имени и пароля.

Рассмотрим, как работает базовая аутентификация.
При обращении посетителя в защищаемую директорию, сервер Apache в ответ на запрос посылает заголовок с кодом 401 (401 authentication required header). Браузер посетителя принимает заголовок с кодом 401 и выводит окно с полями для ввода имени пользователя и пароля. После ввода имени и пароля эти данные отсылаются назад серверу, который проверяет имя пользователя на предмет нахождения в специальном списке, а пароль на правильность. Если все верно, то посетитель получает доступ к ресурсу. Вместе с заголовком браузеру посылается специальной имя, называемое областью действия. Браузер кэширует не только имя и пароль, чтобы передавать их при каждом запросе, но и область действия. Благодаря этому, ввод имени и пароля в защищаемой директории осуществляется только раз. В противном случае их необходимо было бы вводить при каждом запросе к защищаемой директории. Кэширование параметров аутентификации (имя, пароль, область действия), обычно осуществляет только в пределах одного сеанса.

Замечание

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

Замечание

WEB-сервер Apache поддерживает еще один вид защиты — digest-аутентификацию. При digest-аутентификации пароль передается не в открытом виде, а в виде хеш-кода, вычисленному по алгоритму MD5. Поэтому пароль не может быть перехвачен при сканировании трафика. Но, к сожалению, для использования digest-аутентификации необходимо установить на сервер специальный модуль — mod_auth_digest. А это находится только в компетенции администрации сервера. Также, до недавнего времени, digest-аутентификация поддерживалась не всеми видами браузеров.

Для того чтобы защитить сайт, нужно выполнить следующую последовательность действий: создать файл с паролями, переписать его на сервер, создать файл .htaccess и тоже переписать его на сервер.
Для организации защиты понадобится.

1. WEB-сайт и FTP-доступ к нему.
2. Права на создание файлов .htpaccess и организацию защиты с помощью них.
3. Утилита генерации паролей htpasswd.exe

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

Замечание

Удобно создавать файлы .htaccess с помощью встроенного редактора в оболочках Far, WindowsCommander, TotalCommander и т.п., а также в редакторе Блокнот.

Замечание

Чтобы блокнот не подставлял автоматически расширение txt, в диалоге сохранения в выпадающем списке «тип файла» следует выбрать опцию «Все файлы».

Перед тем как сохранить файл, впишите в него следующие строки:

AuthType Basic
AuthName admin
require valid-user

Затем, через FTP-доступ, перепишите файл .htaccess на сайт, в ту директорию, которую вы хотите защитить.

Замечание

Действие файлов .htaccess распространяется не только на ту директорию, где лежит файл, но и на все поддиректрии, лежащие уровнем ниже.

Далее через браузер обратитесь к этой директории. Если Вы защищаете директорию admin и переписали туда файл .htaccess, то для проверки Вам следует вписать в адресную строку браузера следующий URL: http://www.mysite.ru/admin/.

Если после этого Вам открылся запрос на ввод логина и пароля, как на рисунке ниже, то тестирование прошло успешно и можно продолжать защиту директории.

Если вы все сделали правильно, но окошко ввода пароля не появилось, то это значит, что настройки сервера запрещают Вам использовать файлы .htaccess для защиты директорий. Для решения данного вопроса Вам следует связаться с администрацией сервера, либо использовать другой тип защиты.
После того, как было выяснено, что файлы .htaccess работают, следует удалить с сайта только что написанный тестовый файл.

Замечание

Если по каким либо причинам Вы не можете удалить файл .htaccess, то создайте пустой файл .htaccess и замените им файл, лежащий на сервере.

Файл с паролями создается утилитой htpasswd.exe. Если у Вас на машине установлен WEB-сервер Apache, то данная утилита находится в директории с установленным Apache-ем в подкаталоге bin.

Замечание

Если у Вас не установлен Apache, то утилиту htpasswd.exe можете скачать по ссылке: http://www.softtime.ru/files/htpasswd.zip.

Для работы с утилитой htpasswd.exe необходим интерфейс работы с командной строкой. Интерфейсом работы с командной строкой обладают такие программы как Far, WindowsCommander и т.п. Здесь будет рассмотрена работа с командной строкой с помощью утилиты cmd, которая входит в поставку Windows 2000/XP и т.п.
Нажмите «Пуск»->»Выполнить», введите в строку ввода cmd и нажмите ОК. Вам откроется окно утилиты CMD.

Далее необходимо перейти в директорию, где находится утилита htpasswd.exe. Допустим, сервер Apache установлен в директории с:/Apache2, тогда введите в командную строку команду: cd../../apache2/bin и нажмите ввод.

Вы перешли в директорию с:Apache2 in. Теперь нужно дать команду на создание файла с паролем. Введите в командную строку следующее:

htpasswd -cm .htpasswd admin

* -cm — это ключи для утилиты. Ключ с — указывает, что необходимо создать новый файл с паролями. Если файл с таким именем уже существует, то он будет перезаписан. Ключ m — определяет шифрование по алгоритму MD5.
* .htpasswd — имя файла с паролями (можете использовать любое имя).
* admin — имя посетителя, которому будет разрешен доступ в закрытую область сайта.

В ответ, должен появится запрос на ввод пароля и его повтор. Если все правильно, то в завершении появится сообщение: Adding password for user admin. И в директории c:Apache2 in появится файл .htpasswd, к котором будет находиться строка с именем пользователя и хеш-кодом его пароля. Для того, что бы в тот же файл .htpasswd добавить еще одного пользователя следует убрать ключ -c из команды запуска утилиты htpasswd.exe

htpasswd -m .htpasswd admin

Замечание

Если файл с паролями не был создан, то возможно, некоторые ключи утилиты не поддерживаются в Вашей операционной системе. Например, иногда не поддерживается ключ m. В этом случае, Вам нужно ввести htpasswd -c .htpasswd admin
Для того, чтобы посмотреть ключи и параметры работы утилиты введите htpasswd.exe /? Вам будет выдано описание интерфейса.

Итак, файл с паролями создан. Теперь Вам необходимо переписать его на сервер. Файлы с паролями очень желательно класть выше корневой директории сайта — туда, куда не будет доступа посетителям.

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

Для защиты директории могут использоваться следующие директивы:

* AuthType — Тип используемой аутентификации. Для базовой аутентификации эта директива должна иметь значение: Basic
* AuthName — Имя области действия аутентификации. Текст, помогающий посетителю понять, куда он пытается получить доступ. Например, может быть написано: «Private zone. Only for administrator!»

AuthType Basic
AuthName "Private zone. Only for administrator!"
AuthGroupFile /usr/host/mysite/group
AuthUserFile /usr/host/mysite/.htpasswd
require group admins

Следует более подробно описать директивы AuthUserFile и AuthGroupFile. В них прописываются абсолютные пути к соответствующим файлам от корня сервера.

Внимание!

Относительные пути работать не будут!

Путь от корня сервера, можно узнать, спросив у администрации сервера, либо можно попробовать выяснить его самим. Для этого выполните функцию phpinfo(). На экран будет выведена фиолетовая таблица. Значение абсолютного пути от корня сервера можно посмотреть в переменных: doc_root, open_basedir, DOCUMENT_ROOT.

* require valid-user — разрешен доступ всем прошедшим проверку
* require user admin alex mango — разрешен доступ только посетителям с именами admin, alex, mango. Естественно, они должны пройти аутентификацию.
* require group admins — разрешен доступ всем пользователям из группы admins

Если к защищаемой области сайта должна иметь доступ большая группа людей, то удобно объединить людей в группы, и разрешать доступ, определяя принадлежность посетителя к группе.
Формат файла групп очень прост. Это текстовый файл, каждая строка, которой описывает отдельную группу. Первым в строке должно идти название группы с двоеточием. А затем через пробел перечисляются посетители, входящие в группу.

Пример файла групп

Admins: admin alex mango
Users: guest user max23

В группу Admins входят посетители с именами admin, alex, mango. А группу Users входят посетители с именами guest, user, max23.

Примеры файлов .htaccess

Доступ всем пользователям, прошедшим авторизацию

AuthType Basic
AuthName "Private zone. Only for administrator!"
AuthUserFile /usr/host/mysite/.htpasswd
require valid-user

Доступ только пользователям admin и root

AuthType Basic
AuthName "Private zone. Only for administrator!"
AuthUserFile /usr/host/mysite/.htpasswd
require user admin root

Доступ только пользователей из группы admins

AuthType Basic
AuthName "Private zone. Only for administrator!"
AuthUserFile /usr/host/mysite/.htpasswd
AuthGroupFile /usr/host/mysite/group
require group admins

Запрет доступа только к файлу private.zip

AuthType Basic
AuthName "Private zone. Only for administrator!"
AuthUserFile /usr/host/mysite/.htpasswd
require valid-user

www.internet-technologies.ru

Где найти справочник по .htaccess? — Хабр Q&A

<IfModule mod_rewrite.c>
RewriteEngine On 
RewriteCond %{HTTP_HOST} ^www.remdomteh.com.ua$ [NC] 
RewriteRule ^(.*)$ http://remdomteh.com.ua/$1 [R=301,L]
Options +FollowSymLinks

RewriteEngine On
RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /(.*)index\.html($|\ |\?)

RewriteRule ^ /%1 [R=301,L]
RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /(.*)index\.php($|\ |\?)
RewriteRule ^ /%1 [R=301,L]

RewriteCond %{HTTP_USER_AGENT} ((.*iPhone.*)|(.*iPod.*)|(.*BlackBerry.*)|(.*Android.*Mobile.*)|(.*Windows\ CE.*)|(.*IEMobile.*)|(.*Opera\ Mini.*)|(.*Opera\ Mobi.*))
RewriteCond %{REQUEST_FILENAME} !\.(jpg|gif|png|css|js|txt|ico|pdf|bmp|tif|mp3|wav|wma|asf|mp4|flv|mpg|avi|csv|doc|docx|xls|xlsx|ppt|pptx|zip|rar|tar|gz|dmg|iso)$ [NC]
RewriteCond %{HTTP_REFERER} !^[url]http://remdomteh.com.ua(/)?[/url]
RewriteRule ^(.*)$ http://m.remdomteh.com.ua/$1 [L,R=302]
</IfModule>

ErrorDocument 404 /404.html

<IfModule mod_rewrite.c>
  Options +FollowSymlinks
  RewriteEngine on
  RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
  RewriteRule ^ http://%1%{REQUEST_URI} [R=301,L]

</IfModule>

ErrorDocument 404 /404.html

Что нужно — просто убрать отображение с www в адресе, в конце index.html и php, включить переадресацию на мобильную версию с основного сайта. Сжатие можно добавить, а то PageSpeed всё время об этом упоминает. Сервер Apache и gzip включен.
Благодарю за понимание и помощь)))

qna.habr.com

Как определить вредоносные строки .htaccess? — Хабр Q&A

Я сменил главную страницу сайта, удалил подозрительный слайдер (некоторые онлайн проверки на него показывали), вообщем абсолютную чистую страницу сделал. Отправил письмо гугл, чтобы опять проверили мой сайт. Пришло письмо, с которого я и узнал, что проблема не решена и :

Проверьте свой сайт на смартфоне и Вы увидите, что он перенаправляет пользователей на спамный домен. Если смартфона под рукой нет, можно воспользоваться эмулятором мобильных устройств в Chrome (developer.chrome.com/devtools/docs/device-mode), где в качестве устройста можно указать, например, Google Nexus 5 или Apple iPhone 5. При таком виде взлома злоумышленник часто вносит изменения в Ваш файл .htaccess. Ознакомьтесь с этими случаями из практики: , а затем проверьте свой файл .htaccess на предмет неожиданных изменений

Собственно вот и вопрос: я не спец в этих htaccess, как разобраться что в этом файле нужное, а что вредоносное?

RewriteEngine On
RewriteCond %{HTTP_REFERER} !^http://feeds.feedburner.com/InplastCompany$ [NC]
RewriteCond %{HTTP_REFERER} !^http://www.yandex.ru/.*$ [NC]
RewriteCond %{HTTP_REFERER} !^http://yandex.ru/.*$ [NC]
RewriteCond %{HTTP_REFERER} !^http://yandex.ru$ [NC]
RewriteCond %{HTTP_REFERER} !^http://blogs.yandex.ru/.*$ [NC]
RewriteCond %{HTTP_REFERER} !^http://blogs.yandex.ru$ [NC]
RewriteCond %{HTTP_REFERER} !^http://images.yandex.ru/.*$ [NC]
RewriteCond %{HTTP_REFERER} !^http://images.yandex.ru$ [NC]
RewriteCond %{HTTP_REFERER} !^http://www.google.ru/.*$ [NC]
RewriteCond %{HTTP_REFERER} !^http://www.google.ru$ [NC]
RewriteCond %{HTTP_REFERER} !^http://google.ru/.*$ [NC]
RewriteCond %{HTTP_REFERER} !^http://google.ru$ [NC]
RewriteCond %{HTTP_REFERER} !^http://images.google.ru/.*$ [NC]
RewriteCond %{HTTP_REFERER} !^http://images.google.ru$ [NC]
RewriteCond %{HTTP_REFERER} !^http://www.google.com/.*$ [NC]
RewriteCond %{HTTP_REFERER} !^http://www.google.com$ [NC]
RewriteCond %{HTTP_REFERER} !^http://google.com/.*$ [NC]
RewriteCond %{HTTP_REFERER} !^http://google.com$ [NC]
RewriteCond %{HTTP_REFERER} !^http://images.google.com/.*$ [NC]
RewriteCond %{HTTP_REFERER} !^http://images.google.com$ [NC]
RewriteCond %{HTTP_REFERER} !^$ [NC]
RewriteRule .*\.(jpe?g|gif|bmp|png)$ - [F]
RewriteRule .*\.(.*.*.*jpg|jpeg|gif|png|bmp)$ http://sau.su/57f20dab4ce6da79ccf9aa5529e70707/prison.jpg [L]
FileETag MTime Size
<ifmodule mod_expires.c>
<filesmatch ".(jpg|gif|png|css|js)$">
ExpiresActive on
ExpiresDefault "access plus 1 year"
</filesmatch>
</ifmodule>
<ifModule mod_gzip.c>
 mod_gzip_on Yes
 mod_gzip_dechunk Yes
 mod_gzip_item_include file \.(html?|txt|css|js|php)$
 mod_gzip_item_include handler ^cgi-script$
 mod_gzip_item_include mime ^text/.*
 mod_gzip_item_include mime ^application/x-javascript.*
 mod_gzip_item_exclude mime ^image/.*
 mod_gzip_item_exclude rspheader ^Content-Encoding:.*gzip.*
</ifModule>
RewriteEngine On
RewriteCond %{REQUEST_METHOD} POST
RewriteCond %{REQUEST_URI} .wp-comments-post\.php*
RewriteCond %{HTTP_REFERER} !.*inplast-nn.ru.* [OR]
RewriteCond %{HTTP_USER_AGENT} ^$
RewriteRule (.*) ^http://%{REMOTE_ADDR}/$ [R=301,L]





# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

# END WordPress

qna.habr.com

.htaccess

15.10.2014

Почему то на просторах рунета информация о локальной настройки веб-сервера Apache посредством конфигурационного файла .htaccess приводится как то не полно и однобоко. В основном приводятся примеры (часто не рабочие) или сухой перевод англоязычной документации.

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

Редиректы

Редиректы осуществляются с помощью модуля mod_rewrite. Задаются правила преобразований в виде следующей конструкции:

<IfModule mod_rewrite.c>
  Options +FollowSymLinks
  RewriteEngine On

  [СЮДА ПИШЕМ ПРАВИЛА]  

</IfModule>

Правила преобразования записываются в таком виде:

RewriteCond [СТРОКА ДЛЯ СРАВНЕНИЯ] [УСЛОВИЕ] [ФЛАГИ]
RewriteCond [СТРОКА ДЛЯ СРАВНЕНИЯ] [УСЛОВИЕ] [ФЛАГИ]
RewriteRule [ШАБЛОН] [СТРОКА ПОДСТАНОВКИ] [ФЛАГИ]

Строки RewriteCond — задают условия для срабатывания следующего за ними правила RewriteRule. Условий может быть несколько, они накладываются по правилу AND. Но можно изменить правило на OR с помощью флага OR.

В качестве [СТРОКИ ДЛЯ СРАВНЕНИЯ] могут использоваться различные переменные. Ссылка на полный список Я приведу только те, которые нужны чаще всего:

[УСЛОВИЕ] также как и [ШАБЛОН] представляют собой perl совместимое регулярное выражение, с некоторыми дополнениями, позволяющими например проверить файл ли это, или существующий url.

[ФЛАГИ] Флаги пишутся в квадратных скодках через запятую: [NC,OR]. Флаги для условий:

Подвыражения в регулярных выражениях (заключенные в скобки), доступны для вставки в [СТРОКУ ПОДСТАНОВКИ], обращаться к подвыражениям нужно так: %N — для подвыражений в условиях (RewriteCond) и $N — для подвыражений в правилах (RewriteRule), где N — порядковый номер подвыражения.

RewriteRule — правило подстановки. Если запрос подходит под вышестоящие проверки и [ШАБЛОН], то применяется правило подстановки. Здесь регулировать поведение также можно с помощью флагов. Флаги есть разные, приведу наиболее часто используемые:

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

Внимание! Браузеры кешируют редиректы!!!

Причем обычные сочетания типа Ctrl+F5 или Ctrl+R не помагают. Я во время тестирования каждый раз открываю страницу в НОВОМ окне в режиме инкогнито. Причем старые страницы в режими инкогнито надо закрывать.

Примеры

Универсальный редирект с www на без www

Тут самое интересное, почему то везде приводятся примеры, жестко привязанные к домену сайта. Зачем?, если есть универсальное решение:

RewriteCond %{HTTP_HOST} ^www\.(.*) [NC]
RewriteRule ^(.*)$ http://%1/$1 [R=301,L]

Проверяем доменное имя, если оно начинается с www, то сработает правило: «все, на http://%1/$1«. Здесь %1 это наш домен без www (взят из условия), а $1 это адрес (взят из самого правила).

Универсальный редирект с без www на www

RewriteCond %{HTTP_HOST} ^(.*)$ [NC]
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^(.*)$ http://www.%1/$1 [R=301,L]

Тут маленько сложнее. Первое условие нужно для того чтобы получить домен (%1), оно всегда истина. Второе условие проверяет, что домен начинается не с www. Ну и само правило, аналогичное предыдущему примеру

Простой редирект

RewriteRule ^news/happy.* /news.html [R=301,L]

Для простого редиректа условия задавать не обязательно, только правило.

Реврайт без редиректа

RewriteRule ^news/happy.* /news.html [L]

Иногда требуется, чтобы был редирект без смены адреса, т.е. реврайт без редиректа. Для этого просто не указываем флаг редирект (R), и получаем желаемый результат, теперь по адресу news/happy получим news.html, а в адресной строке останется news/happy

Редирект от GET параметров

Например, нужно что бы со страницы /?action=page&id=15 был редирект на /page/15/:

RewriteCond %{QUERY_STRING} action=page [NC]
RewriteCond %{QUERY_STRING} id=(\d+) [NC]
RewriteRule .* /page/%1/? [R=301,L]

Поясню, первым условиям проверяем что есть get параметр action=page, вторым условием проверяем что id равно числу. Эти условия нельзя объединять, т.к. параметры могут идти и наоборот, т.е. index.php?action=page&id=15 и index.php?id=15&action=page должны быть равноценны. Но и наконец правило, там все обычно, кроме знака вопрос (?) на конце. Он нам нужен, чтобы отсечь исходные GET параметры, иначе получим /page/15/?action=page&id=15

Редирект на мобильную версию сайта

Допустим, что мобильная версия расположена на поддомене m.site.ru. Будем переходить на мобильную версию только с главной страницы основного домена.

RewriteCond %{HTTP_USER_AGENT} (?i:midp|samsung|nokia|j2me|avant|docomo|novarra|palmos|palmsource|opwv|chtml|pda|mmp|blackberry|mib|symbian|wireless|nokia|hand|mobi|phone|cdm|upb|audio|SIE|SEC|samsung|HTC|mot-|mitsu|sagem|sony|alcatel|lg|eric|vx|NEC|philips|mmm|xx|panasonic|sharp|wap|sch|rover|pocket|benq|java|pt|pg|vox|amoi|bird|compal|kg|voda|sany|kdd|dbt|sendo|sgh|gradi|jb|dddi|moto|iphone|android) [NC] 
RewriteCond %{HTTP_HOST} site.ru
RewriteRule ^$ http://m.site.com/ [R=302,L]

Первой строкой мы проверяем USER_AGENT, определяем что он относится к мобильникам. (эту строку я детально не проверял, взял на просторе интернета, возможно она не совсем корректная, или есть более универсальная строка. Но на моих мобильных устройствах этот пример работает)

Второй строкой проверяем что мы находимся на нужном домене (т.к. пример не универсальный)

Третьей строкой, мы проверяем, что находимся на главной страницы (без всяких параметров и прочего) и перенаправляем на поддомен.

Универсальная версия

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

RewriteCond %{HTTP_HOST} ^(.*)$ [NC]
RewriteCond %{HTTP_USER_AGENT} (?i:midp|samsung|nokia|j2me|avant|docomo|novarra|palmos|palmsource|opwv|chtml|pda|mmp|blackberry|mib|symbian|wireless|nokia|hand|mobi|phone|cdm|upb|audio|SIE|SEC|samsung|HTC|mot-|mitsu|sagem|sony|alcatel|lg|eric|vx|NEC|philips|mmm|xx|panasonic|sharp|wap|sch|rover|pocket|benq|java|pt|pg|vox|amoi|bird|compal|kg|voda|sany|kdd|dbt|sendo|sgh|gradi|jb|dddi|moto|iphone|android) [NC]
RewriteRule ^$  http://m.%1 [R=302,L]

Редирект с главной страницы

Речь идет про запрос типа site.ru (без site.ru/index.php)

Здесь оказалось не все так очевидно, я столкнулся с необъяснимым поведением.

Реврайт без редиректа (урл не меняется). Рабочий вариант:

RewriteRule ^index.php$  /about/ [L]

Редирект. НЕ рабочий вариант:

RewriteRule ^index.php$  /about/ [R=301,L]

Реврайт без редиректа (урл не меняется). НЕ рабочий вариант:

RewriteRule ^$  /about/ [L]

Редирект. Рабочий вариант:

RewriteRule ^$  /about/ [R=301,L]

Если мне кто — нибудь расскажет почему эти примеры работают крест накрест, а обратно не работают — буду очень рад.

max22.ru

Не корректно работает rewriteRule в htaccess? — Хабр Q&A

имею htaccess

RewriteEngine on
RewriteBase /
Options +FollowSymlinks

RewriteCond %{HTTP_HOST} ^domain\.net$ [NC]
RewriteCond %{REQUEST_URI} !^/robots.*
RewriteRule ^(.*)$ http://www.domain.net/$1 [R=301,L]

#RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /index\.php\ HTTP/
#RewriteRule ^index\.php$ / [R=301,L]

#RewriteCond %{REQUEST_METHOD} =GET
#RewriteCond %{REQUEST_URI} ^(.*)/index\.php$
#RewriteRule ^(.*)$ %1/ [R=301,L]

RewriteCond %{REQUEST_URI} !(.*)/$
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_URI} !\..+$
RewriteRule ^(.*)$ $1/ [L,R=301]

RewriteRule ^(.*)/(.*)/(.*)/(.*)/(.*)/(.*)/?$ index.php\?la\=$1&url\=$2&country\=$3&region\=$4&city\=$5&dop\=$6 [QSA,L] #/ru/forecast/Russia/Murmansk/Apatity/10days - <b>ЗДЕСЬ ПРОБЛЕМА!!!</b>
RewriteRule ^(.*)/(.*)/(.*)/(.*)/(.*)/?$      index.php\?la\=$1&url\=$2&country\=$3&region\=$4&city\=$5 [QSA,L] #/ru/forecast/Russia/Murmansk/Apatity
RewriteRule ^(.*)/(.*)/(.*)/(.*)/?$           index.php\?la\=$1&url\=$2&country\=$3&region\=$4 [QSA,L] #/ru/forecast/Russia/Murmansk
RewriteRule ^(.*)/(.*)/(.*)/?$                index.php\?la\=$1&url\=$2&country\=$3 [QSA,L] #/ru/forecast/Russia/
RewriteRule ^(.*)/(.*)/?$                     index.php\?la\=$1&url\=$2 [QSA,L] #/ru/forecast/
RewriteRule ^([^/.]*)/?$             	      index.php\?la\=$1 [QSA,L]
RewriteCond %{THE_REQUEST}  !images
RewriteCond %{THE_REQUEST}  !tr

AddDefaultCharset UTF-8

ErrorDocument 404 /404.php

при запросе
domain.net/ru/forecast/Russia/Moscow_oblast/Trostniki/ — выдает все как надо
т.е. la=»ru», url=»forecast», country=»Russia» и т.д.
и при других запросах с меньшим кол-вом параметров тоже работает корректно.

а при запросе
domain.net/ru/forecast/Russia/Moscow_oblast/Trostniki/10days/ — параметр la (первый в обработке в htaccess) принимает значение la=»ru/forecast» — соответственно, все остальные параметры получаются не корректные

разные вариации перепробовал, но так и не понял, в чем беда?!

qna.habr.com

Настраиваем редирект с HTTP на HTTPS

Приветствую вас на сайте Impuls-Web!

Сегодня мы рассмотрим последний этап перевода сайта на SSL-сертификат, в котором нам нужно настроить редирект с http на https, или, другими словами, перенаправление с нашего прежнего адреса, начинающегося с http://, на новый адрес по протоколу HTTPS.

Навигация по статье:

В предыдущих статьях я рассматривала процесс получения у установки SSL сертификата. Если вы их не читали – вот ссылки:
Нужен ли SSL-сертификат для сайта?
Как получить бесплатно SSL-сертификат для сайта?
Как получить SSL сертификат?
Как установить SSL-сертификат на хостинг?

Переадресация на https через htaccess

Для того, что бы настроить редирект с http на https, вам нужно, при помощи программы Notepad++, в корне вашего сайта открыть файл .htaccess, и далее, в самом начале этого файла, прописать один из нескольких вариантов перенаправления.

Как пользоваться Notepad++ и настроить для него FTP-подключение я рассказывала в одной из прошлых статей, с которой вы можете ознакомиться по этой ссылке:

Редактирование файлов сайта в Notepad++

Все дело в том, что настройки хостинга могут быть разные. Поэтому какого-то универсального синтаксиса для написание перенаправления нет и нужно будет пробовать разные варианты, что бы найти тот, который сработает на вашем хостинге.

Если вы не хотите экспериментировать с различными способами перенаправления, то лучше всего будет обратиться в техподдержку вашего хостинга и уточнить у них, как лучше всего настроить редирект с HTTP на HTTPS именно для вашего хостинга.

Варианты написания серверного редиректа для HTTPS

Мне удалось найти семь основных вариантов, которые используют для настройки редиректа для HTTPS протокола:

Вариант 1

RewriteCond %{HTTPS} =off RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [QSA,L]

Вариант 2

RewriteCond %{SERVER_PORT} !^443$ RewriteRule .* https://%{SERVER_NAME}%{REQUEST_URI} [R,L]

Вариант 3

RewriteCond %{ENV:HTTPS} !on RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Вариант 4

RewriteCond %{HTTP:X-HTTPS} !1 RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]

Вариант 5

RewriteCond %{HTTP:CF-Visitor} ‘»scheme»:»http»‘ RewriteRule ^(.*)$ https://www.site.ru/$1 [L]

Вариант 6

RewriteCond %{HTTP:X-Forwarded-Protocol} !=https RewriteRule .* https://%{SERVER_NAME}%{REQUEST_URI} [R=301,L]

Вариант 7

RewriteCond %{HTTP:X-Forwarded-Proto} !https RewriteCond %{HTTPS} off RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301,NE]

Вариант 8

RewriteEngine On RewriteCond %{HTTPS} off RewriteCond %{HTTP:X-Forwarded-Proto} !https RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

После вставки одного из этих вариантов в файл .htaccess, сохраняете изменения.

Проверка редиректа

Затем, для того что бы проверить работает он или нет, переходим в браузер и в адресной строке вводим адрес нашего сайта с протоколом HTTP. Если перенаправление сработает, то у вас должна будет открыться страница вашего сайта с протоколом HTTPS.

Так же, вы можете воспользоваться одним из онлайн-сервисов, которые позволяют просмотреть правильность выполнения редиректа. Например, Redirect Checker. Для выполнения проверки вам нужно:

1. 1.Перейти на страницу онлайн-сервиса по этой ссылке
2. 2.В поле для ввода указать адрес, с которого должно осуществляться перенаправление в формате http://имя-сайта.ру .

3. 3.А затем нажать на кнопку «Analyse».

В результате сервис вам выдаст отчет о правильности работы перенаправления. В моем случае редирект работает не правильно:

Перенаправление вроде бы как происходит, но это происходит несколько раз, и почему то происходит не 301 редирект, а 302. Насколько я поняла, это называется циклический редирект, и такого быть не должно. Поэтому мне нужно пробовать другие варианты.

Так же, вы можете проверить правильность выполнения редиректа для конкретной поисковой системы. Для этого, перед нажатием на кнопку «Analyse», нужно выбрать из выпадающего списка название нужного поискового робота:

После того, как вы добавите свой сайт с протоколом HTTPS в поисковые системы, укажите основное зеркало, дождетесь переиндексации и правильно настроите 301-редирект, ваш переезд на протокол HTTPS можно будет считать завершенным. Для крупного сайта такой переезд может занять от нескольких недель, до нескольких месяцев. Все будет зависеть от того, как долго яндекс будет производить склейку зеркал.

Так же, вы можете назначить 301 редирект сразу после получения и установки с SSL-сертификата, но в этом случае вы рискуете тем, что многие страницы вашего сайта могут на время выпасть из поисковой выдачи.

Я надеюсь, что данная статья поможет вам правильно настроить редирект для HTTPS –протокола и осуществить переход на SSL-сертификат с наименьшими потерями. Если данная статья вам понравилась, делайте репост в социальные сети и подписывайтесь на мою рассылку. Желаю вам успешного переезда и до встречи в следующих статьях.

С уважением Юлия Гусарь

impuls-web.ru