Доступ за пределы рабочей директории __DIR__ Всем привет! Написал сайт на PHP MVC, сделал разделение на backend, common, frontend. Настроил в openserver домены x1.local - директория frontend, admin.x1.local - директория backend. Так вот, как подключить файлы из директории common в frontend и backend? namespace'ы не использую. Пробовал так: в frontend/web/index.php прописал require __DIR|__.'/../../common/config/config.php - ошибка. В этом случае __DIR__ - это эже текущая директория index.php, т.е. frontend/web. Как решить проблему? help me В разделе новичком не смогли решить этот вопрос
@Konstant1n Это называется защита. Фича. Запрет на выход с корневой директории. Что бы ты не смог шариться по всем файлам. Можно настроить но не нужно. В предыдущей теме ответил. Плюс эта конструкция явно не правильная
@Konstant1n, я вам на этот вопрос пару дней назад отвечал. Уточняющих вопросов не было. Значит, все понятно. В абс. путях лучше не использовать /../ (для этого есть dirname() и т.п.). Какая ошибка? См. описание маг. констант в руководстве. __DIR__ содержит каталог тек. исполняемого файла. Как выше написали, может быть и запрет на доступ к произвольным каталогам (см. open_basedir), только обычно все же это НЕ «запрет на выход с корневой директории», потому что нормой считается держать внутр. кухню сайта выше корня (многие хостеры сейчас дефолтом поддерживают такую структуру). Ели вам разрешено «подниматься» только на один уровень выше корня, «распараллеливайте» не только служебные каталоги, но и публичные внутри «каталога сайта», например: frontend frontend_public backend backend_public common Или делайте за пределами корня восходящую иерархию: frontend_public backend_public php/frontend php/backend php/common Корни морды и админки в ряде случаев можно совместить, направляя запросы в нужный фронт в зависимости от имени хоста (в наших админках даже есть механизм, когда фронт админки передает управление расположенному в этом же каталоге фронту морды, когда запрос попал в админку «по ошибке»). --- Добавлено --- Если вы определяете базу во фронте, находящемся в корне, попробуйте так: define('INCLUDE_PATH',dirname(__DIR__).'/common/'); Или для второго показанного мной варианта так: define('INCLUDE_PATH',dirname(__DIR__).'/php/common/'); --- Добавлено --- Я давал ссылку на пример использования. Если непонятно: require(INCLUDE_PATH.'config/config.php');
попробую. дело в том что, через админку я редактирую заметки, загружаю файлы и т.п. Куда лучше сохранить эти файлы, если структура такова backend/web/ - для админки frontend/web/ - для юзеров ?
Благодарю Вас, получилось PHP: define('INCLUDE_PATH',dirname(__DIR__,1).'/common'); function autoLoad( $className ) { $directories = [ INCLUDE_PATH.'/config/', INCLUDE_PATH.'/helpers/', INCLUDE_PATH.'/exceptions/', __DIR__.'/controllers/', __DIR__.'/core/', INCLUDE_PATH.'/core/', __DIR__.'/models/', __DIR__.'/widgets/', ]; foreach ( $directories as $directory ) { $file = $directory.$className.'.php'; if ( file_exists($file) ) { require $file; return true; } } return false; } spl_autoload_register('autoLoad' ); date_default_timezone_set(Config::TIME_ZONE); --- Добавлено --- css и js файлы можно тоже вынести? Я вынес, но с подключением проблемы и можно ли из папки common картинки выводить?
@Konstant1n Если у тебя нету цели отделить (именно отделить) админку апи и сайт (для последующего размещения на разных серверах) зачем тебе вообще поддомены? Подумай об этом.
@Konstant1n зачем ты тогда создаешь общие файлы и думаешь над их подключением в пределах одного сервера? Где здесь логика? Можно конечно создать общий файл и копировать его при доставке на сервер плюс разные конфиги на прод и дев но это уже совсем другая история
Надеюсь, вы приняли к сведению мое замечание: на два уровня выше корня на шареде могут и «не пустить». Не знаю, как вам, а мне непривычно видеть константу с _PATH на конце имени, значение кот. не имеет трэйлинг слеша. --- Добавлено --- Естественно, обвес должен находиться в паблик каталоге. Доступ к нему со стороны браузера осуществляется по адресам, а не по путям лок. ФС --- Добавлено --- У нас, например, ресурсы для админки часто подтягиваются из «третьего» источника, которым пользуется много экземпляров админок.
что это такое? --- Добавлено --- чтобы не плодить файлы с одинаковым содержимым. в common у меня: config/config.php core/model.php core/view.php core/route.php helpers/hml.php ... надо сделать изменения, меняю только здесь и все
shared hosting, услуга вирт. хостинга по-нашему. --- Добавлено --- ...в каталог др. «сайта» тоже могут «не пустить», поэтому я показал вариант с разными корнями, но общим для корней надкаталогом.
@Konstant1n Еще раз повторю. Определись с целю. Если тебе нужно отделить фронт от бека это одно. Тут не может быть никаких общих файлов. Если тебе просто хочется иметь admin.site.com просто потому что хочется тебе не обязательно создавать два отдельных сайта создай один. Укажи admin.site.com как алиас к site.com и в роуте (в единой точке входа) уже определяй куда идет запрос в зависимости от домена
Ну возможность-то может быть. Есть и морда, и админка, часть файлов используется совместно. А если есть только что-то одно, то эти файлы, естественно, используются только тем, что есть. --- Добавлено --- Я об этом писал выше. Только нужно предусмотреть возможность «выплевывания» из админки запроса, предназначенного не ей.
Вообще эта идея пришла с yii2.0 advanced. Разделяю, с соображения безопасности: в frontend/web только для отображения данных, а в backend/web добавлю авторизацию для админа + папку закрою паролем (это может быть и лишним), и тут вьюшки будут уже с формами для редактирвоания, а для юзеров вьюшки без форм редактирования - просто текст. Раньше у меня все было в одной папке x1.local, админка в x1.lcal/admin - сказали так опасно, что по хорошему надо спрятать админку и форму авторизации, потом посмотрел yii2.0.... сейчас вот разбираюсь как же лучше, оптимальнее, безопаснее
@Konstant1n, вьюшки и т.п. должны быть закрыты ото всех от прямого доступа. --- Добавлено --- ...В паблик каталогах вы оставляете максимум фронт морды/админки и, естественно, статик обвес.
нет. для этого же админка есть - backend. форма авторизации есть --- Добавлено --- да, они все закрыты - вне папки web, т.е. в frontend/views --- Добавлено --- Код (Text): такова структура: backend common frontend core models controllers views web css js img index.php .htaccess load.php
@nospiou, не, он хочет вынести админку на др. хост, насколько я понимаю. Это я ему подсказал в др. теме. Ну или в йи подсмотрел, как написал.
не, админка остается на том же хосте. может неправильно написал вопрос админка и сайт в одном хосте, но в разных папках - backend и frontend, их общая часть в common
backend это php frontend это html js админка это админка все изменения делаются через гит проще всего создать ярлык. У тебя концепция не правильная потому и сложно обьяснить.
@nospiou, не только. Морду сайта в целом тоже называют фронтэндом, а админку – бэкэндом. --- Добавлено --- Конечно из контекста должно быть понятно, о чем речь.
А что тогда означает backend/web/ - для админки frontend/web/ - для юзеров ? Я думал, это разные корни. --- Добавлено --- Естественно, совмещать это в одном контексте – идиотизм Хотя ты вот написал, и в принципе вполне понятно, о чем речь. Без шуток. --- Добавлено --- фронт фронта бэк фронта фронт бэка бэк бэка Все понятно. Никакой неоднозначности --- Добавлено --- Mля, фронт бэка фронта – это фронт-контроллер морды что ли получается
@miketomlin Ну как минимум звучит интересно. Но что пытается сделать тс я так и не понял. Дать доступ к php коду пользовательской части и скрыть php код админки? А какой в этом смысл? Там что то секретное? drop table я везде могу написать. А ключи с разным доступом и так выносятся в конфиг.
@nospiou, с учетом его последнего уточнения мне, видимо, просто разделить в основном бэк фронта и бэк бэка, а также вынести в бэкэнде (php) общие либы в отдельный каталог, хотя последнее, возможно, касается и фронтэнда (js и проч. обвес, например шрифты или картинки). --- Добавлено --- ...и как к этим общим элементам обращаться.