Ich habe Bedenken, die denen ähneln, die hier angesprochen wurden. Ich verwende Composer, um Amazon AWS-Komponenten zu installieren und einen SES-Dienst (E-Mail) einzurichten.
Laut Amazon Dokumentationmuss ich einschließen autoload.php um die Klassen zu verwenden, die ich installiert habe. Dies bedeutet, dass die autoload.php muss sich in meinem Webverzeichnis (/var/www/html) befinden.
Ich habe die Antwort auf die zuvor erwähnte SO-Frage nicht vollständig verstanden, aber sie besagt im Wesentlichen, dass sich das Anbieterverzeichnis NICHT im Webverzeichnis befinden sollte. Aber wenn ich das tue, wie soll ich das tun? require das autoload.php Datei, die sich im Verzeichnis /vendor befindet?
Insgesamt bin ich sehr verwirrt darüber, wie ich das richtig einrichten soll. Jede Hilfe wäre willkommen.
Bearbeiten: Dies Artikel schlägt auch vor, den Ordner /vendor/ in das Webverzeichnis zu legen. Ist das die Norm? Auf welche Sicherheitsrisiken muss ich achten? Da sich in keinem der Ordner index.html-Dateien oder ähnliches befinden, können die Verzeichnisse aller installierten Dateien angezeigt und frei aufgerufen werden. Das kann doch nicht gut sein?
Das “Web-Verzeichnis” ist das Verzeichnis, das direkt per HTTP an alle Personen weitergeleitet wird, die nach der richtigen URL fragen. Wenn also jemand denkt, dass es einen Ordner „/foo“ gibt, der auf Ihrer Domain gehostet wird, und Sie keine Vorkehrungen getroffen haben, und es tatsächlich diesen Ordner gibt und er keine Datei enthält, die als Verzeichnisindex dienen würde, irgendjemand Wenn Sie fragen, erhalten Sie wahrscheinlich die Verzeichnisliste dieses Ordners, in der alle Dateien aufgelistet sind.
Nun der Unterschied zwischen einem solchen im Web gehosteten Ordner und dem require Aussage in PHP ist, dass PHP keine URL verwendet, die auf einen öffentlich zugänglichen HTTP-gehosteten Ordner zeigt, sondern einen Dateisystempfad verwendet, der auf eine Datei verweist.
Und die meisten Anfänger verwechseln das: Da es bei PHP auf Anfängerniveau nur darum geht, eine Reihe von Skripten im Webverzeichnis zu verteilen, die viel HTML mit Links zu anderen Skripten ausgeben, bekommen sie die Vorstellung, dass die Links in HTML und der Datei enthalten sind Pfade in PHP sind gleich und müssen es sein. Das ist falsch. Sie müssen nicht gleich sein, sie sind gleich, weil kein besserer Ansatz gewählt wurde.
So wird also eine moderne Webanwendung aufgebaut. Wenn Sie das gesamte Projekt bereitstellen, wird möglicherweise das Hauptverzeichnis auf dem Server aufgerufen /var/www/projectX. In diesem Container befinden sich einige Dateien wie z /var/www/projectX/composer.json. Aus diesem Grund wird es auch ein Verzeichnis geben /var/www/projectX/vendor. Außerdem wäre irgendwo ein PHP-Skript, auf das zugegriffen wird (ich verzögere die Information, WIE darauf zugegriffen wird), und dieser Ort sollte entweder A sein) /var/www/projectX/script.php oder B) /var/www/projectX/public/script.php. Diese beiden Skripte möchten von Composer bereitgestellte Klassen verwenden und müssen das automatische Laden enthalten.
Aufgrund des Dateispeicherorts muss das Skript an Speicherort A ausgeführt werden require 'vendor/autoload.php';und das Skript an Speicherort B benötigt require '../vendor/autoload.php';. Dies ist einfach eine Frage der Verwendung des korrekten relativen Pfads vom Skript zur Autoload-Datei. Sie könnten in beiden Fällen sogar einen absoluten Pfad verwenden: require '/var/www/projectX/vendor/autoload.php'; wird auch funktionieren. Der Hauptpunkt hier ist: Es spielt keine Rolle, WIE Sie diese autoload.php-Datei benötigen, solange sie vom Skript ausgeführt wird. Der Pfad beeinflusst nichts.
Jetzt das HTTP-Hosting und der Zugriff auf die Skripte. Auf dem Webserver ist mindestens ein Verzeichnis konfiguriert, das als Hauptverzeichnis der Domain nach außen hin offengelegt wird. Das nennt man DOCUMENT_ROOT, und es kann ÜBERALL sein. Nun hängt es von der Konfiguration Ihres Servers ab, welches Verzeichnis vorausgewählt ist und ob Sie diese Einstellung ändern können (entweder durch Verwalten Ihres Servers auf der Befehlszeile oder durch Klicken auf einige Einstellungen in einer GUI).
Wenn Ihr Server das Verzeichnis hat /var/www/projectX als Dokumentenstamm festgelegt, kann die ganze Welt auf das Skript im Fall A zugreifen http://example.com/script.phpsowie das Skript im Fall B als http://example.com/public/script.phpund auch der Vendor-Ordner als http://example.com/vendor/.... Das ist nicht toll, könnte aber durch Platzierung vermieden werden .htaccess enthaltene Dateien oder schränken den Zugriff auf andere Weise ein.
Die bessere Lösung besteht darin, dem Server mitzuteilen, dass er nur das Verzeichnis bedienen soll /var/www/projectX/public als Dokumentenstamm. Dadurch wird der HTTP-Zugriff auf Skript A und den Herstellerordner verhindert, und der Zugriff auf Skript B erfolgt über http://example.com/script.php.
In beiden Fällen beinhalten beide Skripte erfolgreich das automatische Laden von Composer, da die Einschränkungen des HTTP-Zugriffs nicht für den Dateisystemzugriff gelten.
Bei schlechtem Website-Hosting können Sie nur das erste Szenario verwenden, wobei das einzige für Sie zugängliche Verzeichnis direkt das Dokumentstammverzeichnis ist, ohne dass eine Methode zum Ändern vorhanden ist.
Anspruchsvolleres Website-Hosting verwendet ein festes Unterverzeichnis wie public oder html oder webroot als Dokumentenstamm, sodass Sie vertrauliche Dateien davor verbergen können, jemals über HTTP bereitgestellt zu werden.
Beim besten Website-Hosting können Sie auswählen, welches Unterverzeichnis als Dokumentenstamm gehostet werden soll.
In jedem Fall ist der Pfad, der von einem Skript zu Composers autoload.php zeigt, überhaupt nicht betroffen.
