0,0
рейтинг
14 января 2013 в 12:32

Разработка → Полезные хаки и сниппеты для .htaccess из песочницы



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

О предназначении файла .htaccess знает каждый веб-разработчик. На базовом уровне он позволяет управлять доступом к каталогам сайта. Но добавляя в него различные дополнительные фрагменты кода, с ним можно сделать и много других интересных вещей.

Если же вам нужны базовые сведения о предназначении данного файла, то вы можете получить из нашей статьи введение в .htaccess (перевод данной статьи не делал, так как там основы, их достаточно в русскоязычном сегменте Сети, но если будет проявлен интерес, то можно и ее перевести для полноты картины — прим. переводчика), в которой достаточно подробно раскрыты все аспекты его применения.

Итак, полезные примеры использования. htaccess:

1. Управление доступом к файлам и каталогам

Защита паролем — это одно, но иногда может понадобиться полностью блокировать доступ пользователей к определенному файлу или папке. Обычно это относится к системным папкам, таким, например, как includes, доступ к которым должны иметь приложения, но не пользователи.

Чтобы сделать это, поместите данный код в файл. htaccess и сохраните его в каталоге к которому закрываете доступ:

deny from all

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

order deny,allow 
deny from all 
allow from xxx.xxx.xxx.xxx

где xxx. xxx. xxx. xxx — это ваш IP. Для задания разрешенных диапазонов IP-адресов вы можете заменить три последние цифры. Например, написав вместо них «0/12», вы зададите диапазон IP-адресов одной сети, что избавит вас от необходимости вводить в список все разрешенные IP-адреса отдельно.

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

<Files .htaccess>
 order allow,deny
 deny from all
 </Files>

Если вы хотите указать определенные IP-адреса которым надо запретить доступ, перечислите их при помощи allow from.

Если же вы хотите заблокировать доступ к файлам определенного типа, используйте этот код:

<FilesMatch ".(htaccess|htpasswd|ini|phps|fla|psd|log|sh)$">
 Order Allow,Deny
 Deny from all
 </FilesMatch>

2. Запрет на просмотр директорий

Для предотвращения просмотра директорий сайта добавьте в .htaccess следующий код:

Options All -Indexes

Если же по какой-то причине вы хотите разрешить просмотр всех директорий, используйте код:

Options All +Indexes

3. Ускорение времени загрузки за счет сжатия файлов

Сжимать можно файлы любого типа. Например, для сжатия HTML-файлов добавьте код:

AddOutputFilterByType DEFLATE text/html

Для сжатия текстовых файлов используйте:

AddOutputFilterByType DEFLATE text/plain

Вы также можете сжать JavaScript или включить сжатие для других различных типов файлов командами:

AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/rss+xml

Кроме того, вы можете сжать все ваши JavaScript, HTML и CSS файлы при помощи GZIP. Для этого используйте следующий код:

<IfModule mod_gzip.c>
mod_gzip_on Yes
mod_gzip_dechunk Yes
mod_gzip_item_include file \.(html?|txt|css|js|php|pl)$ 
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>

4. Защита сайта от вставки изображений с других ресурсов

Если вы хотите запретить добавление ссылок на изображения со сторонних ресурсов, добавьте в файл .htaccess код:

RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?yourdomain.com [NC]
RewriteRule \.(jpg|jpeg|png|gif)$ - [NC,F,L]

Не забудьте заменить yourdomain.com на имя вашего домена.

5. Блокировка посетителей, перешедших с определенного домена

Если вы не хотите видеть на своем сайте пользователей с конкретного домена, то вы можете запретить им доступ. Например, пользователей с нежелательных ресурсов (сайты для взрослых, хакерские сайты и т. д.) вы можете перенаправлять на страницу 403 Forbidden. Для этого необходимо включить mod_rewrite, хотя, как правило, он включен по умолчанию. Добавьте в .htaccess код:

<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{HTTP_REFERER} bannedurl1.com [NC,OR]
RewriteCond %{HTTP_REFERER} bannedurl2.com [NC,OR]
RewriteRule .* - [F]
</ifModule>

Вам необходимо заменить bannedurl1.com и bannedurl2.com доменами, которые вы хотите внести в черный список. Вы можете использовать флаг [NC], указывающий, что введенное доменное имя нечувствительно к регистру. Флаг [F] указывает на тип действия, в данном случае — отображение ошибки 403 Forbidden. Если вы хотите запретить несколько сайтов, используйте флаги [NC, OR] для каждого домена, если же вы хотите запретить использование одного домена — используйте только флаг [NC].

6. Блокирование запросов от определенных браузеров

Если в ваших файлах журналов появились записи о посещении особых браузеров (это могут быть имитирующие работу браузера боты или пауки), вы можете запретить им доступ на свой сайт, добавив несколько строк в. htaccess:

RewriteEngine On 
RewriteBase / 
SetEnvIfNoCase Referer "^$" bad_user
SetEnvIfNoCase User-Agent "^badbot1" bad_user
SetEnvIfNoCase User-Agent "^badbot2" bad_user
SetEnvIfNoCase User-Agent "^badbot3" bad_user
Deny from env=bad_user

Замените badbot1, badbot1 и т. д. именами ботов из вашего журнала. Это закроет посторонним программам доступ к вашему сайту.

7. Кэширование файлов

Кэширование файлов — еще один способ ускорить загрузку вашего сайта. Вот то, что вам нужно прописать в .htaccess:

<FilesMatch ".(flv|gif|jpg|jpeg|png|ico|swf|js|css|pdf)$">
Header set Cache-Control "max-age=2592000"
</FilesMatch>

Вы можете добавить больше типов файлов (или удалить некоторые из них) в перечисленныq в данном примере список файлов. Вы также можете указать время сохранения файлов в кэше (в секундах) при помощи переменной max-age.

8. Отключение кэширования для разных типов файлов

Если вы не хотите кэшировать определенные типы файлов, можно не включать их в список. Однако иногда файлы могут сохраняться в кэше даже не будучи явно перечисленными в списке, в этом случае вы можете отключить кэширование для них индивидуально. Чаще всего отключать кэширование требуется для динамических файлов, таких как сценарии. Пример требуемого для этого кода:

<FilesMatch ".(pl|php|cgi|spl|scgi|fcgi)$">
Header unset Cache-Control
</FilesMatch>

Просто укажите типы файлов, для которых нужно отключить кэширование.

9. Обход диалога загрузки

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

AddType application/octet-stream .pdf
AddType application/octet-stream .zip
AddType application/octet-stream .mp3

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

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

AccessFileName htac.cess

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

11. Замена стартовой страницы сайта

Если вы хотите установить главную страницу, отличную от стандартной (index.html, index.php, index.htm и т. д.), добавьте следующий код в файл .htaccess:

DirectoryIndex mypage.html

Замените mypage.html на URL страницы, которую вы хотите использовать в качестве главной.

12. Перенаправление на защищенное соединение HTTPS

Если вы используете HTTPS и хотите перенаправить пользователей на защищенные страницы вашего сайта, добавьте в файл .htaccess следующие строки:

RewriteEngine On
RewriteCond %{HTTPS} !on
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}

13. Ограничение максимального размера загружаемых файлов в PHP, максимального размера передаваемых данных, максимального времени выполнения скриптов и т.п.

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

php_value upload_max_filesize 15M

Вы можете установить любое значение, в примере размер файла ограничен 15M (MБ). Помимо этого вы можете ограничить максимальный размер передаваемых при загрузке в PHP данных:

php_value post_max_size 10M

Вы можете заменить 10М на любое требуемое вам значение. Если вам не требуется постоянное выполнение скриптов, вы можете ограничить время их выполнения с помощью строки:

php_value max_execution_time 240

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

php_value max_input_time 180

Установите вместо 180 любое требуемое вам время (в секундах).

14. Скрытие типов файлов

Иногда нужно, чтобы пользователи не знали, какие типы файлов находятся на вашем сайте. Один из способов скрыть эту информацию — сделать так, чтобы все ваши файлы отображались как HTML или PHP файлы:

ForceType application/x-httpd-php
ForceType application/x-httpd-php

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

Источник

UPD (спасибо akuma) расширение РНР для скрытия формата файлов приведено как пример и использование этого трюка в реальном проекте может оказаться небезопасным
Алексей Савченко @Extremum
карма
30,0
рейтинг 0,0
Пользователь
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (82)

  • +1
    По моему, никогда не надо делать так, что бы все ваши файлы отображались как PHP. Это очень плохо и небезопасно.
    • 0
      Согласен, но здесь скорее рассматривается опциональная возможность, а PHP приведен как пример возможного расширения.
      • +7
        Да, но статья называется «Полезные....».
        И некоторые новички могут подумать, что это полезная фича, и использовать ее на своих сайтах.
        • 0
          Да, спасибо, дополнил.
  • +2
    15. Защита паролем.

    Иногда нужно, чтобы доступ к некоторым ресурсам сайта был разрешён только определённым пользователям.
    Запустив команду «htpasswd /home/pathto/.htpasswd user1» и введя 2 раза пароль, создастся файл .htpasswd примерно такого содержания:
    user1:31/a7xzJFbFoo
    user2:7JK9iJEedT8hA

    В файл .htaccess добавляем следующие строки:

    AuthUserFile /home/pathto/.htpasswd
    AuthType Basic
    AuthName «Secret Place»
    require valid-user

    Доступ теперь возможен только при введении правильного имени пользователя и пароля.
  • +6
    Вот прямо сейчас смотрю Яндекс. Кит 3
    events.yandex.ru/events/kit/3/

    Цитата от лектора: «Если вы еще используете апач, то прямо сейчас с этого момента перестаньте его использовать»

    Ну и дальше пространно говорит о наличии фундаментальных проблем в апаче и предлагает перейти на nginx.
    • +2
      Не так давно все рабочие проекты стали держать только под nginx — всё супер. При этом перейти с apache на nginx не составляет никакого труда. Даже реврайты все можно легко регулярками конвертнуть. Настройки более удобные и гибкие.
      • 0
        Ага, кстати, для тех у кого многострочные .htaccess и кому лень вручную их переписывать для nginx в сети есть конверторы.
        winginx.ru/htaccess
      • +1
        Поддерживаю, тоже давно всё перевёл. Некоторые трудности были только с MediaWiki из-за её очень «особого» подхода к работе ЧПУ, но как уже сказал коллега чуть выше, это все можно нивелировать настройкой конфига.

        А для Wordpress, к примеру, есть небольшой модуль, который фиксит работу ЧПУ на nginx и вовсе из коробки.
      • 0
        mod_flv под nginx нет, так бы тоже пересел
        • +6
          А ngx_http_flv_module не подходит? nginx.org/ru/docs/http/ngx_http_flv_module.html
          • 0
            Эээ, вы мне глаза открыли :) Попробую обязательно и перееду. если все хорошо, а то меня подвисания апача в lockf при нападении пары поисковых ботов уже достали.
            • +1
              Вы уж как-то иногда выглядывайте из норы — ему знаете сколько лет уже? :)
              • 0
                Да мне что-то даже в голову не приходило :)
      • 0
        Все бы прекрасно, если бы можно было скрипты под разными юзерами запускать. Иначе взлом одного сайта ставит под удар все остальные автоматом.
        • 0
          Nginx вообще скриптов не запускает. Будьте спокойны. =)
          • 0
            А кто же запускает обработку PHP-скриптов? ;-)
            • 0
              php-fpm, он от другого пользователя работает (может работать)
              • 0
                Именно! И работает он как раз под одним юзером, что фактически дает права на все проекты общие. В этом и проблема.
                • +2
                  Это уж как настроите. Можете настроить на каждый сайт свой пул со своим юзером.
                  • 0
                    Я что-то про это уже читал, правда там, как я понял, нужно еще с бубном местами скакать, что не добавляет удобства. Есть какой-то нормальный мануал на эту тему, не в курсе?
                    • +1
                      Да не было там никогда никаких заморочек, пулы от разных пользователей у меня работали ещё когда php-fpm существовал только в виде патча на php 5.2.

                      Настроек там по пальцам пересчитать:
                      php.net/manual/en/install.fpm.configuration.php

                      Но как видно, можно не просто пользователя задать, но и chroot для каждого сделать, плюс ограничения по ресурсам.

                      Каждый пул — это отдельная секция в конфиге, вот пример:
                      www.if-not-true-then-false.com/2011/nginx-and-php-fpm-configuration-and-optimizing-tips-and-tricks/#php-fpm-pools-configuration
                      • 0
                        Спасибо, буду вникать.
    • –3
      Вспомнился анекдот.
      В ресторане вскакивает грузин(г) и орет
      (г) — Грузины лучше чем армяне
      Подскакивает армянин (а)
      (а) — Чем лучше? ЧЕМ?
      (г) — Чем армяне.
      • –16
        Алаверды:


        :)
  • +10
    Если же вам нужны базовые сведения о предназначении данного файла, то вы можете получить из нашей статьи введение в .htaccess

    Честно говоря разочарован. Думал здесь я найду реально что-то интересное, а не простой репост того, чего итак в сети уже полно в 100500 копиях.
    • 0
      В следующий раз более взвешенно подойду к выбору темы. Просто я наверное не встречал настолько полного собрания, поэтому и заинтересовало.
  • 0
    Если все скрипты лежат в папке system достаточно ли в нее кинуть отдельный файл .htaccess с записью Deny From all
    И как это сделать не плодя файлы .htaccess?
    • 0
      Да, достаточно. И плодить файл не придется, один файл на всю папку system.
      Другое дело, что по хорошему она должна быть на одном уровне с public_html, чтобы еще и таким способом исключить прямого обращения.
      • 0
        а разве «прямое обращение» не заблокировано в Apache «по-умолчанию» правилом <Files ~ "^\.ht">?
        • 0
          Мы обсуждали ограничение доступа к скриптовым файлам, а не файлам .ht*
          • 0
            Прошу прощения. я " она должна быть" прочитал как про файл .htaccess а не каталог system :(
    • 0
      Да, действие .htaccess распространяется на все вложенные папки, если вы не перекрываете правила специально во вложенных папках
      • 0
        А как принуительно запретить переопределение настроек в каталогах ниже?
        • 0
          Засунуть правило в Location
        • 0
          Еще это можно сделать через AllowOverride.
  • +1
    Например, выбирая с 0 на 12 вы будет задавать диапазон IP-адресов одной сети

    Это надо перевести.
    • 0
      Да, моя ошибка, спасибо что подсказали. Уже исправил.
      • +1
        Опечатка в «будете» осталась.
        Например, выбирая 0/12 вы будет задавать диапазон

        Лучше так:
        Например, написав вместо них «0/12», вы зададите диапазон

        Простите за занудство.
        • 0
          Наоборот — спасибо за помощь. Ваш вариант лучше, его и добавил.
  • 0
    Знающие люди, подскажите несведущему.
    1. Управление доступом к файлам и каталогам

    order deny,allow 
    deny from all 
    allow from xxx.xxx.xxx.xxx

    А можно ли открывать доступ не по ip, а по адресу сайта? Или ip & адрес сайта?
    • 0
      По домену? Насколько я знаю — никак.
      • 0
        Можно, если IP пользователя потом reserve-резолвится на этот домен. К сожалению, этого обычно не так просто добиться.
    • 0
      Это IP клиента, а не сервера. Какой у клиента может быть «адрес сайта»?
      • 0
        Например, для определенного сайта сделать возможность доступа к файлам на моем сервере, а для остальных закрыть доступ.
        • 0
          для определенного сайта сделать возможность доступа к файлам на моем сервере

          Это оксюморон, извините. Когда компьютер, на котором хостится «сайт» (то есть который, кроме прочего, обслуживает http-запросы в качестве сервера) выступает в роли клиента, он не обладает такими свойствами «сайта», как «домен» или «адрес сайта». В роли клиента он имеет только IP, использующийся для сетевого соединения, по которому и возможна блокировка.
          • +1
            А вот и не правда. В роли клиента может быть не только ип адрес, может быть и fqdn (если конечно ДНС запись имеется и ДНС настройки сервера позволяют резолвинг делать).
            Строка типа:

            Deny from .net whatever.com

            запретит доступ к ресурсу если клиентский ип резолвится как 123-whatever-dsl.provide.net или natted.whatever.com
            Днс проверка происходит вне зависимости от того что стоит в HostnameLookups — On или Off.
            • 0
              Правда, правда. Softlink спрашивает как разрешить доступ определённому «сайту» (хосту, очевидно), а остальным запретить. Если остальные на том же IP, как вы им это запретите?
    • 0
      Можно делать редирект через RewriteRule, если домен указан не правильно.
      Но это по сути не ограничение доступа
  • НЛО прилетело и опубликовало эту надпись здесь
    • +2
      Не нужно так делать. Что если я пользователь Андроид-смартфона, захожу на ваш сайт, но я не хочу ставить ваше приложение?
    • +1
      Перенаправлять насильно — плохое решение. Правильно — задать один раз вопрос «У нас есть приложение, хотите установить?», и если пользователь откажется, то больше не упоминать.
  • +1
    Бессвязная и нелогичная выборка директив конфига апача, непонятно зачем поданная в контексте htaccess.
    А новички, на которых эта статья рассчитана, после фраз типа «написав вместо них «0/12», вы зададите диапазон IP-адресов одной сети» — запутаются окончательно.
    В целом все выглядит а ля «смотрите, какие опции конфига апача я знаю».
    • –1
      Вы знаете, я ее переводил потому что действительно новичок и многого из этого не знал, а 0/12 в ступор не вогнали. Судя по количеству добавивших статью в избранное — не одному мне это оказалось интересно.
      • 0
        Местами да, интересно, но директив надергано много, области применения у всех разные, поэтому в избранном статью нет смысла держать — она никак не помогает решить какую-то конкретную задачу.
        • 0
          Если я использую обычный хостинг, а не выделенный сервер, то какой хостер мне разрешит копаться в файлах конфига апача и вносить там свои правки? И я могу одним файликом задать конкретные правила для конкретной директории без того, чтобы лезть в конфигурационный файл сервера, так чем это плохо и почему не решает конкретных проблем?
          • 0
            Статья не про htaccess, а про настройку апача и пхп.
            Тот факт, что эти настройки можно вынести в htaccess, как и написано в начале статьи, «знает любой web-разработчик».
            То есть проблему недоступности конфигов на хостинге статья-то решает (в принципе одним только своим заголовком), а вот солянка из опций апача а пхп не понятно с какой целью и по каким принципам подобрана.
            • 0
              Я задам вопрос автору, если ответит дополню статью.
  • 0
    Обход диалога загрузки


    Спасибо, при загрузке PDF файлов очень поможет — а то клиенты понаставят плагинов для просмотра PDF в браузере, потом спрашивают как сохранить файл.
    • 0
      Да, тоже сталкивался с претензиями «не работает скачивание нашего прайса/предложения/», и даже после объяснения причин все равно у клиента оставалось недовольство полученным результатом.
      • НЛО прилетело и опубликовало эту надпись здесь
        • 0
          Да, вы правы, это не панацея. Лично я применил этот способ на практике только раз — на проекте работающем на Instancms. Там была проблема — у каждого пользователя есть собственное хранилище файлов, куда он может заливать допустимые форматы и давать прямую ссылку на скачивание залитых файлов. Так вот архив .zip скачивался, а архив .rar считывался и выводился набором символов в новой вкладке. Правка в .htaccess помогла решить проблему. Так что от всего не спасает, но некоторые вопросы решает)
    • 0
      При правильных заголовках такого не должно происходить, какие бы плагины не стояли.
  • 0
    Мой вариант: github.com/Claud/.htaccess/blob/master/.htaccess там тоже достаточно полезных правил и в все прокомментировано.
    • 0
      Спасибо, забрал в закладки.
  • 0
    В пп 4 забыты поисковые пауки работающие с изображениями.
    Желательно разрешить поисковым системам ссылаться на ваши изображения.
    Я так же добавил вместо запрета — замену изображения на другое изображение ворам вашего контента.
    У меня воришкам отображается — Читай оригинал на сайте.таком-то!

    RewriteEngine on
    RewriteCond %{HTTP_REFERER} !^$
    RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?(.*)vasilisc.com(.*) [NC]
    RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?(.*)?yandex.(.*) [NC]
    RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?(.*)?google.(.*) [NC]
    RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?(.*)?yahoo.(.*) [NC]
    RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?(.*)?mail.(.*) [NC]
    RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?(.*)?bing.(.*) [NC]
    RewriteRule (.*)?\.(jpg|jpeg|png|gif)$ /путь/к/vasilisc.com/images/bolt2.png [L]
    


    • 0
      Полезное решение, спасибо.

      P.S. /bolt2.png — красноречивое название файла)
  • 0
    А подскажите как сделать работающий редирект с https на http? Уже всё перепробовал, так и забросил.
    Пробовал:
    RewriteCond %{HTTPS} =on RewriteRule .* http://site.ru%{REQUEST_URI} [R=301,L]
    не работает
    RewriteCond % ^443$ [OR] RewriteCond % =on RewriteRule ^(.*)$ http://site.ru/ [R=301,L]
    не работает
    RewriteCond %{HTTPS} on RewriteRule (.*) http://%{HTTP_HOST}%{REQUEST_URI}
    не работает
    • 0
      Попробуйте:

      RewriteEngine On
      RewriteCond %{HTTPS} on
      RewriteRule (.*) http://%{HTTP_HOST}%{REQUEST_URI}
      


      по идее должно работать.
      • 0
        Пробовал, не работает, последняя строка в моём предыдущем сообщении.
        • 0
          Может быть в конфигурации сервера что-то. Вообще по идее должно работать. А до этого у вас не стоит RewriteRule на HTTPS? Понимаю что слишком просто, но иногда ответы на поверхности.
          • 0
            Возможно, техподдержка хостинга не может мне чётко ответить. Но зато чётко говорит, что менять ничего не будут. Нет, не стоит.
    • 0
      А так?

      RewriteEngine On
      
      RewriteCond %{SERVER_PORT} ^443$
      RewriteRule ^.*$ http://%{HTTP_HOST}%{REQUEST_URI} [L,QSA]

      и что значит не работает — ничего не происходит?
    • 0
      DocumentRoot под HTTP и HTTPS разный? Может быть, просто .htaccess не туда пишете.
  • 0
    Защита сайта от вставки изображений с других ресурсов
    Такая защита не даст яндексу и гуглу индексировать картинки.
  • 0
    Может быть, кто-нибудь знает, как запретить перенаправление после rewrite?
    Есть вот такое правило:

    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteCond %{REQUEST_URI} (/m)?/([^/]+)\.(jpg|jpeg|gif|png)$
    RewriteRule .* http:// my.domen.com/user/upload%1/%2.%3

    Сейчас, когда пользователь заходит по ссылке my.domen.com/12345.png, его просто редиректит на полную ссылку на изображение my.domen.com/user/upload/12345.png.
    А можно ли сделать так, чтобы в строке состояния пользователь видел ссылку my.domen.com/12345.png, но показывалось изображение, которое лежит по ссылке my.domen.com/user/upload/12345.png?
    • 0
      Вместо «http:// my.domen.com/user/upload%1/%2.%3» напишите относительный путь к файлу (внутри DocumentRoot), что-то вроде "/user/upload%1/%2.%3".
      • 0
        Спасибо, помогло)
  • 0
    5. Блокировка посетителей, перешедших с определенного домена
    А как запретить вход всем, кроме рефереров с конкретного сайта?

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