Ich suche einen portablen Weg, um die (handliche) $_SERVER['PATH_INFO'] Variable zu erhalten.
Nach einiger Zeit stellt sich heraus, dass PATH_INFO von CGI / 1.1 stammt und nicht immer in jeder Konfiguration vorhanden ist.
Was ist der beste (meist sicherheitsbezogene) Weg, um diese Variable zu erhalten - abgesehen von der manuellen Extraktion (Sicherheitsbedenken).
Nun, ich bin mir (fast) sicher, dass, ohne die% superglobalen Schlüssel $_SERVER zu verwenden, eine alternative Möglichkeit zur Bestimmung von PATH_INFO einfach unmöglich ist, das heißt lets führen zuerst alle $ _SERVER-Schlüssel auf, die wir möglicherweise möglicherweise verwenden:
Wir müssen natürlich die letzten beiden ignorieren. Jetzt sollten wir ( Ich weiß das nicht genau, ich nehme nur an, weil du das gesagt hast ) alle Schlüssel filtern, die in dem von dir angegebenen Link existieren ( welches BTW ist offline ATM ), das lässt uns mit der folgende Schlüssel:
Was Ihren Kommentar zu Anthonys antwort
Sie jonglieren jetzt nur noch Variablen.
SCRIPT_FILENAMEist ein Teil des CGI Spez. Es wird nicht verfügbar sein, wennPATH_INFOist nicht verfügbar. Wie fürREQUEST_URI, es ist apaches mod_rewrite Spezifisch. - LiraNuna
Ich betreibe LightTPD / 1.4.20-1 (Win32) mit PHP 5.3.0 als CGI, cgi.fix_pathinfo = 1 und $_SERVER['REQUEST_URI'] steht mir sehr zur Verfügung , ich kann mich auch daran erinnern dieselbe Variable in den Tagen, als niemand mod_rewrite verwendet hat, also meine ehrliche bescheidene Vermutung ist, dass du in diesem Punkt ganz falsch liegst . In Bezug auf den Schlüssel SCRIPT_FILENAME kann ich diesen einen ATM nicht testen. Trotzdem, wenn wir unsere Augen wirklich hart schließen und glauben, dass du Recht hast, bleibt uns nur eine Variable:
Ich versuche hier nicht hart zu sein (und ich glaube immer noch, dass es mehr Lösungen gibt), aber wenn PHP_SELF der einzige Schlüssel ist, mit dem wir arbeiten sollen ( vorausgesetzt, es gibt keine Impositionen auf PHP_SELF selbst ) gibt es nur noch eine Lösung:
Diese Funktion sollte funktionieren, es kann jedoch Probleme mit der Konstante __FILE__ geben, da sie den Pfad zur Datei zurückgibt, in der die __FILE__ -Konstante deklariert ist, und nicht den Pfad zum angeforderten PHP-Skript , deshalb gibt es das $ whatToUse: Sie können durch 'SCRIPT_FILENAME' ersetzen oder wenn Sie wirklich an das glauben, was Sie sagen, verwenden Sie einfach '.php' .
Sie sollten auch lesen, warum Sie PHP_SELF nicht verwenden sollten .
Wenn das nicht für Sie funktioniert, tut es mir leid, aber mir fällt noch etwas ein.
BEARBEITEN - Noch etwas mehr für Sie:
REQUEST_URI Apache-spezifisch ist?) PHP_SELF vs PATH_INFO vs SCRIPT_NAME vs REQUEST_URI Ich denke, hier ist ein Trick, um "path_info" auf andere Weise zu erhalten:
%Vor% Zum Beispiel Zugriff auf eine URL wie: Ссылка , der Wert von $path_info wäre : "/some/path/here"
Es funktionierte für mich in verschiedenen Apache-Servern unter Windows und Linux, aber ich bin mir nicht 100% sicher, ob es "sicher" und "portabel" ist, ich teste es nicht in "ALLEN" Serverkonfigurationen, aber scheint zu funktionieren ...
Bearbeiten: Ohne SCRIPT_NAME und vorausgesetzt, Sie haben DOCUMENT_ROOT (oder können Sie selbst definieren / entdecken) und vorausgesetzt, Sie haben SCRIPT_FILENAME, dann:
%Vor%Auch @ Anthony (nicht genug rep zu kommentieren, sorry): Mit str_replace () wird überall in der Zeichenfolge übereinstimmen. Es funktioniert nicht garantiert, du möchtest es nur am Anfang anpassen. Außerdem funktioniert Ihre Methode, nur einen Schrägstrich zurück (über strrpos) SCRIPT_NAME zu bestimmen, nur, wenn das Skript unter der Wurzel ist, weshalb Sie besser diffind script_filename gegen docroot.
Es hängt von den Definitionen für "tragbar" und "sicher" ab.
Lass mich sehen, ob ich verstanden habe:
1) Sie sind nicht an CLI interessiert:
2) Sie möchten PATH_INFO in allen OS + HTTP Server + PHP Kombination haben:
Hmmm ... PHP_INFO, im $ _SERVER-Array, wird von PHP nur unter bestimmten Bedingungen an ein laufendes Skript übergeben, abhängig von der oben erwähnten Software. Es ist nicht immer verfügbar. Dasselbe gilt für das gesamte $ _SERVER-Array!
Kurz gesagt: " $ _ SERVER hängt vom Server ab " ... also kann eine portable Lösung nicht auf $ _SERVER übertragen werden ... (um nur ein Beispiel zu nennen: Wir haben ein Tutorial für Richten Sie PHP / CGI $ _SERVER-Variablen auf dem NginX-HTTP-Server unter kbeezie.com/view/php-self-path-nginx/) ein
3) Trotz allem, was oben erwähnt wurde, ist es erwähnenswert, dass es möglich ist, PATH_INFO durch Anwendung regulärer Ausdrücke zu erhalten, wenn wir die angeforderte vollständige URL als String zur Verfügung haben und andere PHP-String-Funktionen, sicher (auch Validierung der Eingabe-String als eine gültige URI).
Also, vorausgesetzt, wir haben die URL-Zeichenfolge ... dann JA, WIR HABEN eine portable und sichere Möglichkeit, PATH_INFO daraus zu bestimmen.
Nun haben wir zwei klare und fokussierte Implementierungsprobleme:
Unter verschiedenen Möglichkeiten ist hier ein möglicher Ansatz:
1) Mit Ihrem umfassenden und umfassenden Wissen über jede HTTP Server + OS + PHP Versionskombination, überprüfen und versuchen Sie jede Möglichkeit, die URL aus dem $ _SERVER Array zu erhalten (verifizieren Sie 'PHP_SELF', 'QUERY_STRING', 'SCRIPT_FILENAME', "PATH_TRANSLATED", "SCRIPT_NAME", "REQUEST_URI", "PATH_INFO", "ORIG_PATH_INFO", "HTTP_HOST", "DOCUMENT_ROOT" oder was auch immer)
2) Wenn der vorherige Schritt fehlgeschlagen ist, lassen Sie das PHP-Skript einen JavaScript-Code zurückgeben, der "document.URL" zurücksendet. (Das Portabilitätsproblem wurde auf die Clientseite übertragen.)
Dieser hier verlinkte Code tut das.
Das ist meine bescheidene Meinung und Annäherung an das Problem.
Was denkst du?