Установка OpenCart 3
Vorobey - 12 Сентябрь, 2017 - 12:06
Установил и настроил Open Cart 3. На VDS ubuntu 16.04
/home/user/www/example1.com/
В админ панели магазина требуют переноса директории storage за пределы www
Я понимаю что это безопасность.
Но скрипт OC будет иметь обращение и запись в этот каталог, какая разница на каком уровне он находится.
В конфиге nginx доступ из вне закрыт.
storage содержит - кэш и кучи скриптов .sh (на данном этапе мне они ненужны)
Мне интересен вопрос - зачем ее переносить и что делать если сайт будит работать
на обычном хостинге где только /public_htm и всё, а перенести ее надо выше?
Я так понял, потому, что так хочет скрипт админки =) Он не настолько продвинутый, чтобы проверить, действительно ли вы закрыли доступ извне, но по умолчанию вам не доверяет и "думает", что вы обязательно забудете это сделать.
Как вариант - найти нужную строчку и закомментировать.
Лет 15 не видел в глаза, как выглядит обычный хостинг, но припоминаю, что там дают доступ к родительскому каталогу, в котором уже лежит public_html, статистика и т.д. Не думаю, что с тех пор что-то сильно изменилось. Собственно, там же можно будет создать и ваш storage.
Да так и есть. Вот диалог
p.s oc3 очень сильно поменялся...
Ну сделайте один хост
и для него в nginx
root /home/user/www/example2.com/public_html;
Не такая уже страшная проблема.
Ну, я в своей местной статье по NginX тоже опустил эту тему... По хорошему, если бэкэнду нужна файлопомойка (вне БД), то да, есть две причины класть ее в файловой системе отдельно от wwwroot:
1) по соображениям производительности, ибо если "убить" нагрузкой системный раздел - начнутся дикие лаги самого приложения и сервера целиком, есть риск переполнения и потери стабильности, а также на крупных проектах производительности системного раздела тупо не хватит (у меня есть примеры проектов, где подобный storage - это примонтированный программный RAID, который на самом деле является объединением дисков более 30 физических машин).
2) как уже было упомянуто, ради безопасности. Стоит справедливо заметить, что самую большую угрозу безопасности все равно представляет разработчик бэкэнда, который может оставить кучу дыр, но все, что можно сделать на админском уровне - лучше сделать тоже.
Установка масок доступа к файлам должна использоваться строго вкупе с установкой владельца каталогов/файлов.
Смысл в том, чтобы запретить запись в любые каталоги, доступные извне пользователю, от имени которого работает бэкэнд.
Если последний - это www-data, то wwwroot и все его содержимое должно принадлежать другому юзеру, например, root, а маска доступа должна быть установлена как минимум в 755 для каталогов и 644 для файлов, когда их изменение разрешено только руту.
Всю эту малину ломают некоторые виды кривого деплоя. Такие как веб-инсталляторы, желающие что-либо изменить в wwwroot, например, какой-нибудь wwwroot/config/super_config.php, для этого и пишут дурные советы вроде поставьте 777...
Отправить комментарий