Ich habe Bedenken, die denen ähneln, die angesprochen wurden hier . Ich verwende Composer, um Amazon AWS-Komponenten zu installieren, um einen SES-Dienst (E-Mail-Dienst) einzurichten.
Laut der Amazon Dokumentation muss autoload.php , um die von mir installierten Klassen zu verwenden. Das bedeutet, dass autoload.php in meinem Webverzeichnis (/ var / www / html) sein muss.
Ich habe die Antwort auf die oben erwähnte SO-Frage nicht vollständig verstanden, aber es besagt im Wesentlichen, dass das Lieferantenverzeichnis NICHT im Webverzeichnis sein sollte. Aber wenn ich das tue, wie werde ich require die autoload.php Datei, die im / vendor-Verzeichnis ist?
Insgesamt bin ich sehr verwirrt darüber, wie ich das richtig einrichten sollte. Jede Hilfe wäre willkommen.
Bearbeiten: Dieser Artikel schlägt außerdem vor, den / vendor / Ordner in das Webverzeichnis zu stellen. Ist das der Standard? Auf welche Sicherheitsrisiken sollte ich achten? Da sich in keinem der Ordner index.html-Dateien befinden, können die Verzeichnisse aller installierten Dateien frei angezeigt und aufgerufen werden. Das kann doch nicht gut sein.
Das "Web-Verzeichnis" ist das Verzeichnis, das über HTTP direkt an jeden gerichtet wird, der nach der richtigen URL fragt. Also, wenn jemand denkt, dass ein Ordner "/ foo" in Ihrer Domain gehostet ist, und Sie keine Vorkehrungen getroffen haben, und es tatsächlich diesen Ordner gibt und er keine Datei enthält, die als Verzeichnis-Index dienen würde, jeder fragen würde wahrscheinlich die Verzeichnisliste dieses Ordners, alle Dateien auflisten.
Nun besteht der Unterschied zwischen einem solchen Web-gehosteten Ordner und der require -Anweisung in PHP darin, dass PHP keine URL verwendet, die auf einen öffentlich zugänglichen HTTP-Ordner verweist, sondern einen Dateisystempfad, der auf eine Datei verweist >
Und die meisten Anfänger mixen das: Da es sich bei PHP auf Starter-Ebene nur um eine Reihe von Skripten im Web-Verzeichnis handelt, die viel HTML mit Links zu anderen Skripten ausgeben, bekommen sie die Idee, dass die Links in HTML stehen und die Dateipfade in PHP sind gleich und müssen sein. Das ist falsch. Sie müssen nicht gleich sein, sie sind gleich, weil kein besserer Ansatz ausgewählt wurde.
Hier ist also, wie eine moderne Webanwendung aufgebaut wird. Wenn Sie das gesamte Projekt bereitstellen, wird das Hauptverzeichnis auf dem Server möglicherweise als /var/www/projectX bezeichnet. In diesem Container befinden sich einige Dateien wie /var/www/projectX/composer.json . Aus diesem Grund wird es auch ein Verzeichnis /var/www/projectX/vendor geben. Außerdem würde irgendwo ein PHP-Skript sein, auf das zugegriffen wird (ich verzögere die Information WIE es gerade aufgerufen wird), und dieser Ort sollte entweder A) /var/www/projectX/script.php oder B) /var/www/projectX/public/script.php sein. Diese beiden Skripts möchten Composer-Klassen verwenden und müssen das automatische Laden einschließen.
Aufgrund des Dateispeicherorts muss das Skript in Speicherort A require 'vendor/autoload.php'; und das Skript in Speicherort B require '../vendor/autoload.php'; ausführen. Dies ist nur eine Frage der Verwendung des korrekten relativen Pfades vom Skript zur Autoload-Datei. Sie könnten in beiden Fällen sogar einen absoluten Pfad verwenden: require '/var/www/projectX/vendor/autoload.php'; funktioniert auch. 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 Zugriff auf die Skripte. Der Webserver hat mindestens ein Verzeichnis konfiguriert, das der Außenwelt als Hauptverzeichnis der Domäne ausgesetzt ist. Dies wird DOCUMENT_ROOT genannt und kann ANYWHERE 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 indem Sie Ihren Server in der Befehlszeile verwalten oder indem Sie auf einige Einstellungen in einer GUI klicken).
Wenn auf Ihrem Server das Verzeichnis /var/www/projectX als Dokumentenstammverzeichnis festgelegt ist, kann die gesamte Welt auf das Skript in Fall A als http://example.com/script.php sowie auf das Skript in Fall B als http://example.com/public/script.php und auch auf den Anbieter zugreifen Ordner als http://example.com/vendor/... . Das ist nicht gut, könnte aber vermieden werden, indem .htaccess -Dateien in den Inhalt gestellt oder anderweitig eingeschränkt werden.
Die bessere Lösung besteht darin, dem Server mitzuteilen, dass er nur das Verzeichnis /var/www/projectX/public als Dokumentenstammverzeichnis bereitstellt. Dies verhindert den HTTP-Zugriff auf Skript A und den Herstellerordner, und der Zugriff auf Skript B erfolgt über http://example.com/script.php .
In beiden Fällen enthalten beide Skripts erfolgreich das automatische Laden von Composer, da die Einschränkungen des HTTP-Zugriffs nicht auf den Dateisystemzugriff anwendbar sind.
Schlechte Website-Hosting ermöglicht Ihnen nur die Verwendung des ersten Szenarios, mit dem einzigen zugänglichen Verzeichnis für Sie direkt das Dokument root, ohne eine Methode, um es zu ändern.
Ausgereifteres Webshosing verwendet ein festes Unterverzeichnis wie public oder html oder webroot als Dokumentenstammverzeichnis und ermöglicht es Ihnen, sensible Dateien vor der Auslieferung über HTTP zu verbergen.
Mit dem besten Website-Hosting können Sie auswählen, welches Unterverzeichnis als Dokumentstamm gehostet werden soll.
In jedem Fall ist der Pfad, der von einem Skript auf die autoload.php der Komponisten verweist, überhaupt nicht betroffen.
Tags und Links php amazon-web-services composer-php amazon-ses