Pull to refresh

Comments 82

По моему, никогда не надо делать так, что бы все ваши файлы отображались как PHP. Это очень плохо и небезопасно.
Согласен, но здесь скорее рассматривается опциональная возможность, а PHP приведен как пример возможного расширения.
Да, но статья называется «Полезные....».
И некоторые новички могут подумать, что это полезная фича, и использовать ее на своих сайтах.
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

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

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

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

А для Wordpress, к примеру, есть небольшой модуль, который фиксит работу ЧПУ на nginx и вовсе из коробки.
Эээ, вы мне глаза открыли :) Попробую обязательно и перееду. если все хорошо, а то меня подвисания апача в lockf при нападении пары поисковых ботов уже достали.
Вы уж как-то иногда выглядывайте из норы — ему знаете сколько лет уже? :)
Да мне что-то даже в голову не приходило :)
Все бы прекрасно, если бы можно было скрипты под разными юзерами запускать. Иначе взлом одного сайта ставит под удар все остальные автоматом.
Nginx вообще скриптов не запускает. Будьте спокойны. =)
А кто же запускает обработку PHP-скриптов? ;-)
UFO landed and left these words here
Именно! И работает он как раз под одним юзером, что фактически дает права на все проекты общие. В этом и проблема.
Это уж как настроите. Можете настроить на каждый сайт свой пул со своим юзером.
Я что-то про это уже читал, правда там, как я понял, нужно еще с бубном местами скакать, что не добавляет удобства. Есть какой-то нормальный мануал на эту тему, не в курсе?
Да не было там никогда никаких заморочек, пулы от разных пользователей у меня работали ещё когда 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
Вспомнился анекдот.
В ресторане вскакивает грузин(г) и орет
(г) — Грузины лучше чем армяне
Подскакивает армянин (а)
(а) — Чем лучше? ЧЕМ?
(г) — Чем армяне.
Если же вам нужны базовые сведения о предназначении данного файла, то вы можете получить из нашей статьи введение в .htaccess

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

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

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

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

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

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

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

Deny from .net whatever.com

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


Спасибо, при загрузке PDF файлов очень поможет — а то клиенты понаставят плагинов для просмотра PDF в браузере, потом спрашивают как сохранить файл.
Да, тоже сталкивался с претензиями «не работает скачивание нашего прайса/предложения/», и даже после объяснения причин все равно у клиента оставалось недовольство полученным результатом.
UFO landed and left these words here
Да, вы правы, это не панацея. Лично я применил этот способ на практике только раз — на проекте работающем на Instancms. Там была проблема — у каждого пользователя есть собственное хранилище файлов, куда он может заливать допустимые форматы и давать прямую ссылку на скачивание залитых файлов. Так вот архив .zip скачивался, а архив .rar считывался и выводился набором символов в новой вкладке. Правка в .htaccess помогла решить проблему. Так что от всего не спасает, но некоторые вопросы решает)
При правильных заголовках такого не должно происходить, какие бы плагины не стояли.
В пп 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]


А подскажите как сделать работающий редирект с 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}
не работает
Попробуйте:

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


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

RewriteEngine On

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

и что значит не работает — ничего не происходит?
DocumentRoot под HTTP и HTTPS разный? Может быть, просто .htaccess не туда пишете.
Защита сайта от вставки изображений с других ресурсов
Такая защита не даст яндексу и гуглу индексировать картинки.
Может быть, кто-нибудь знает, как запретить перенаправление после 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?
Вместо «http:// my.domen.com/user/upload%1/%2.%3» напишите относительный путь к файлу (внутри DocumentRoot), что-то вроде "/user/upload%1/%2.%3".
5. Блокировка посетителей, перешедших с определенного домена
А как запретить вход всем, кроме рефереров с конкретного сайта?
Only those users with full accounts are able to leave comments. Log in, please.