作曲家：「ベンダー」フォルダはどこに置くべきですか？
対処されたものと同様の懸念があります ここ 。 Composerを使用してAmazonAWSコンポーネントをインストールし、SES（メール）サービスをセットアップしています。
Amazon documentation によると、インストールしたクラスを使用するには、autoload.phpを含める必要があります。これは、autoload.phpが私のWebディレクトリ（/ var/www/html）になければならないことを意味します。
前に述べたSOの質問）に対する答えを完全には理解していませんでしたが、基本的にはベンダーディレクトリをWebディレクトリに含めるべきではないと言っています。/vendorディレクトリにあるrequireautoload.phpファイル？
全体として、これを適切に設定する方法について非常に混乱しています。どんな助けでもいただければ幸いです。
編集：これ この記事では、/ vendor /フォルダーをWebディレクトリに配置することも提案しています。これは標準ですか？どのようなセキュリティリスクに注意する必要がありますか？どのフォルダにもindex.htmlファイルなどがないため、インストールされたすべてのファイルのディレクトリを自由に表示およびアクセスできます。確かにこれは良いことではありませんか？
「ウェブディレクトリ」は、正しいURLを尋ねる人にHTTP経由で直接提供されるディレクトリです。したがって、ドメインでホストされているフォルダ「/ foo」があると誰かが考え、予防策を講じなかった場合、実際にはそのフォルダがあり、ディレクトリインデックスとして機能するファイルが含まれていません。尋ねると、おそらくそのフォルダのディレクトリリストが取得され、すべてのファイルがリストされます。
このようなWebホストフォルダーとPHP）のrequireステートメントの違いは、PHPは、パブリックを指すURLを使用しないことです。アクセス可能なHTTPホストフォルダーですが、ファイルを指すファイルシステムパスを使用します。
そして、ほとんどの初心者はこれを混同します：スターターレベルのPHPは、他のスクリプトへのリンクを含む多くのHTMLを出力するWebディレクトリ全体に多数のスクリプトを分散させることです。 HTMLのリンクとPHP）のファイルパスは同じである必要があるという考え。これは間違っています。同じである必要はありません。同じである必要はありません。アプローチが選択されました。
それで、これが現代のウェブアプリケーションがどのように構築されるかです。プロジェクト全体をデプロイする場合、サーバー上のメインディレクトリは/var/www/projectXと呼ばれることがあります。このコンテナの中には、/var/www/projectX/composer.jsonのようないくつかのファイルがあります。このため、ディレクトリ/var/www/projectX/vendorもあります。さらに、どこかにアクセスされている1つのPHPスクリプト（今のところアクセスされている方法の情報を遅らせます））があり、その場所はA）/var/www/projectX/script.phpまたはB）/var/www/projectX/public/script.phpのいずれかである必要があります。これらの2つのスクリプトは、Composer提供されたクラスを使用する必要があり、自動読み込みを含める必要があります。
ファイルの場所が原因で、場所Aのスクリプトはrequire 'vendor/autoload.php';を実行する必要があり、場所Bのスクリプトはrequire '../vendor/autoload.php';を必要とします。これは、スクリプトから自動ロードファイルへの正しい相対パスを使用するだけの問題です。どちらの場合も絶対パスを使用することもできます。require '/var/www/projectX/vendor/autoload.php';も機能します。ここでの重要なポイントは、スクリプトによって実行される限り、autoload.phpファイルをどのように要求するかは問題ではないということです。パスは何にも影響しません。
これで、HTTPがスクリプトをホストしてアクセスします。 Webサーバーには、ドメインのメインディレクトリとして外部に公開されているディレクトリが少なくとも1つ構成されています。これはDOCUMENT_ROOTと呼ばれ、どこでもかまいません。これは、サーバーの構成によって、どのディレクトリが事前に選択されているか、およびその設定を変更できるかどうかによって異なります（コマンドラインでサーバーを管理するか、GUIでいくつかの設定をクリックします）。
サーバーのディレクトリ/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のみをドキュメントルートとして提供するようにサーバーに指示することです。これにより、スクリプトAとベンダーフォルダーへのHTTPアクセスが防止され、スクリプトBへのアクセスはhttp://example.com/script.phpを介して行われます。
どちらの場合も、HTTPアクセスの制限はファイルシステムアクセスに適用されないため、両方のスクリプトにComposerの自動ロードが正常に含まれています。
悪いウェブサイトホスティングでは、最初のシナリオしか使用できず、アクセス可能な唯一のディレクトリは直接ドキュメントルートであり、変更する方法はありません。
publicまたはhtmlまたはwebrootなどの固定サブディレクトリをドキュメントルートとして使用する、より洗練されたWebサイトホスティングにより、機密ファイルがHTTP経由で提供されないようにすることができます。
最高のウェブサイトホスティングでは、ドキュメントルートとしてホストするサブディレクトリを選択できます。
いずれの場合も、スクリプトからComposersautoload.phpを指すパスはまったく影響を受けません。