Pull to refresh

Comments 29

Первое и второе не противоречат друг другу.
Да, так и есть. Поэтому и спрашивается о предпочтении. То бишь, как вам больше нравится
Все четыре пункта друг другу не противоречат.
Какие директории? Зачем скрывать?
Директории, которые относятся к сайту/веб-приложению (например, всякие там class, includes, core, vendors и т.д.).
Скрывать можно по разным причинам. Основная идея — безопасность. Например, какие-то логи, большие картинки из которых потом генерятся маленькие или даже скрипты, чтобы их нельзя было запустить извне.
На самом деле не понятно, почему нужно что-то скрывать. Веб-сервер (будь то Apache, Nginx, или IIS) занимается тем, что отдает браузерам пользователя контент в соответствии с правилами, которые вы ему скажете. Например, отдавать файлы из папки по одним запросам или отдавать сгенерированный каким-то образом контент по другим. Раз у вас есть потребность что-то скрывать, видимо вы разрешили ему отдавать больше, чем нужно было. У вас же не возникает вопрос, как скрыть от веб-сервера, например, содержимое папки /etc. Просто веб-сервер не настроен это содержимое отдавать, и вы спокойны за эту папку.

Т.е. если отвечать на ваш вопрос, то я за второй пункт. Но если рассуждать здраво, сама постановка вопроса не верная.
Правильно! Такое ощущение что cервер настроен так что смотрит в /. Выносите все ненужно из document_root!
UFO just landed and posted this here
Объясните, пожалуйста, подробнее
Пожалуйста, если опрос был полезен для вас, плюсаните, а то недовольные и непонявшие совсем заминисуют :)
опрос полезен только для задающего опрос ;)
Почему же? Разве больше никому не было бы интересно узнать как поступают другие?
Как и большинство опросов.
А как в nginx’е скрываете/защищаете директории?
Ещё можно так:
location *выражение*
{
	deny all;
}


да, это внешне очень похоже на deny from all в хтаксессе, я знаю
А как в nginx разделяете права между разными сайтами? Очень хотелось бы отказаться от Апача, но эта проблема не дает покоя.
2) Не использую apache;
2) Не пишу на php.

Потому вопрос закрытия директорий не стоит в принципе. Скорее, некоторые директории бывает нужно наоборот, открывать.
Использую, где возможно, nginx, поэтому первый вариант лишён большого смысла.

Крайне редко использую public_html в качестве имени для корневого каталога, поэтому второй вариант обычно лишён смысла.

Видимо, правильный ответ в моём случае — при помощи контроля доступа к элементам файловой системы (в т.ч. при помощи SELinix/AppArmor/аналогов) и грамотной настройкой соотв. Web-сервера.
Какая разница, apache, nginx? Проблема в php!

Как 100% отключить — выполнение скриптов в директории. Но есть же другие, где исполнение разрешено и туда что-то можно залить, а =>
1. open_basedir (запретит подниматься выше в php)
2. запретить exec (выполнение внешних команд, не смогут открыть порт/sh)
3. Юзеру php chroot (не поднимется выше директории если вдруг удастся исполнять команды системы/скомпилить бинарник шелла/сделать бэкконнект)
4. Нормальный chmod на папках, а не 755, как «по-умолчанию» (самый верный способ=))
А что, только php скрипт можно залить в public директорию и выполнить его? )
нет естественно, я просто почитал комменты… вроде как в контексте php тут обсуждалось…
location ~ /\. {
	deny all;
}

и именую все «скрытые» директории с точки, как это принято в *nix
одновременно решается проблема со служебными директориями систем контроля версий.
Встречный вопрос:
А зачем нужны скрытые директории на веб сервере от доступа из вне если к ним нельзя подключиться удаленно, в дата центр ехать подключаться через шнур? Думаю не закрывать нужно а сделать авторизацию.
ИМХО какой-то детский сад развели в комментариях. Уже лет N все передовые фреймворки кладут в DOCUMENT_ROOT веб-сервера только лишь index.php и статику. Остальное — от лукавого. Вы можете сколько угодно проверять доступы, писать .htaccess, проверять пути. Но достаточно хоть где-то немного ошибиться системному администратору — и все пропало: habrahabr.ru/post/112237/
Sign up to leave a comment.

Articles