Композитор: куда мне поместить папку "поставщик"?
У меня есть проблемы, аналогичные тем, которые были рассмотрены здесь . Я использую Composer для установки компонентов Amazon AWS для настройки службы SES (электронной почты).
Согласно документации Amazon , мне нужно включить autoload.php, чтобы использовать классы, которые я установил. Это означает, что autoload.php должен быть в моем веб-каталоге (/var/www/html).
Я не до конца понял ответ, данный на вопрос SO, о котором я упоминал ранее, но по сути он говорит что каталог поставщиков не должен находиться в веб-каталоге. Но если я это сделаю, как я буду require autoload.php файл, который находится в каталоге /vendor?
В целом я очень смущен тем, как мне следует это правильно настроить. Любая помощь будет признательна.
Редактировать: В этой статье также предлагается поместить папку /vendor/ в веб-каталог. Является ли это стандартом? На какие риски безопасности мне следует обратить внимание? Потому что нет никаких index.html файлы или все, что находится в любой из папок, каталогов всех файлов, которые были установлены, можно увидеть и получить к ним свободный доступ. Неужели это не может быть хорошо?
1 answers
"Веб-каталог" - это каталог, который напрямую передается по HTTP любому, кто запрашивает правильный URL-адрес. Поэтому, если кто-то думает, что в вашем домене размещена папка "/foo", и вы не приняли мер предосторожности, и на самом деле эта папка есть, и она не содержит файла, который будет использоваться в качестве индекса каталога, любой, кто спросит, вероятно, получит список каталогов этой папки со списком всех файлов.
Теперь разница между такой размещенной в Интернете папкой и require утверждение в PHP заключается в том, что PHP не использует URL-адрес, указывающий на общедоступную размещенную папку HTTP, но использует путь файловой системы, указывающий на файл.
И большинство новичков путают это: поскольку PHP на начальном уровне - это набор сценариев, разбросанных по веб-каталогу, которые выдают множество HTML-файлов, содержащих ссылки на другие сценарии, они понимают, что ссылки в HTML и пути к файлам в PHP одинаковы и должны быть одинаковыми. Это неправильно. Они не должны быть одинаковыми, они одинаковы, потому что не было выбрано лучшего подхода.
Итак, вот как строится современное веб-приложение. При развертывании всего проекта основной каталог на сервере может называться /var/www/projectX. Внутри этого контейнера находятся некоторые файлы, такие как /var/www/projectX/composer.json. Из-за этого также будет каталог /var/www/projectX/vendor. Кроме того, где-то должен быть один PHP-скрипт, к которому осуществляется доступ (я пока откладываю информацию о том, КАК к нему осуществляется доступ), и это местоположение должно быть либо A) /var/www/projectX/script.php, либо B) /var/www/projectX/public/script.php. Эти два сценария хотят использовать классы, предоставляемые композитором, и должны включать автоматическую загрузку.
Из-за расположения файла сценарий в местоположении A должен выполняться require 'vendor/autoload.php';, а сценарий в местоположении B нуждается в require '../vendor/autoload.php';. Это просто вопрос использования правильного относительного пути от сценария к файлу автоматической загрузки. Вы даже можете использовать абсолютный путь в обоих случаях: require '/var/www/projectX/vendor/autoload.php'; также будет работать. Главное здесь вот в чем: не имеет значения, КАК вы требуете, чтобы autoload.php файл до тех пор, пока он выполняется сценарием. Путь ни на что не влияет.
Теперь HTTP-хостинг и доступ к скриптам. На веб-сервере настроен по крайней мере один каталог, который доступен внешнему миру в качестве основного каталога домена. Это называется DOCUMENT_ROOT, и это может быть ГДЕ УГОДНО. Теперь это зависит от конфигурации вашего сервера, какой каталог предварительно выбран, и можете ли вы изменить этот параметр (либо путем администрирования вашего сервера в командной строке, либо нажав некоторые настройки в графическом интерфейсе).
Если на вашем сервере в качестве корневого каталога документа установлен каталог /var/www/projectX, весь мир может получить доступ к сценарию в случае A как http://example.com/script.php, а также к сценарию в случае B как http://example.com/public/script.php, а также к папке поставщика как http://example.com/vendor/.... Это не очень хорошо, но этого можно избежать, поместив файлы .htaccess внутрь или иным образом ограничив доступ.
Лучшее решение - указать серверу, чтобы он обслуживал только каталог /var/www/projectX/public в качестве корневого каталога документа. Это предотвратит HTTP-доступ к сценарию A и папка поставщика, и доступ к сценарию B осуществляется через http://example.com/script.php.
В обоих случаях оба сценария успешно включают автоматическую загрузку Composer, поскольку ограничения доступа HTTP не применяются к доступу к файловой системе.
Плохой хостинг веб-сайтов позволяет вам использовать только первый сценарий, при этом единственным доступным для вас каталогом является непосредственно корневой каталог документа, без способа его изменения.
Более сложный хостинг веб-сайтов с использованием фиксированного подкаталога, такого как public или html или webroot в качестве корневого каталога документа, что позволяет скрывать конфиденциальные файлы от любого доступа по HTTP.
Лучший хостинг веб-сайтов позволяет вам выбрать, какой подкаталог следует размещать в качестве корневого каталога документа.
В любом случае, путь, указывающий от сценария к композиторам autoload.php на это вообще не влияет.