Sie müssen codierte Schrägstriche in Apache zulassen

Ich versuche gerade, eine URL innerhalb einer URL zu platzieren. Zum Beispiel:

http://example.com/url/http%3A%2F%2Fwww.url2.com

Ich bin mir bewusst, dass ich die URL verschlüsseln muss, was ich getan habe, aber jetzt erhalte ich 404eher einen Fehler vom Server als von meiner App. Ich denke, mein Problem liegt bei Apache und kann mit der AllowEncodedSlashes OnDirektive behoben werden .

Ich habe versucht, die Direktive am Ende der httpd.conf ohne Wirkung zu platzieren, und bin mir nicht sicher, was ich als nächstes tun soll. Platziere ich es an der richtigen Stelle? Wenn ja, hat jemand andere Lösungen?

Dieses Problem hängt nicht mit dem Apache-Fehler 35256 zusammen. Es hängt vielmehr mit dem Fehler 46830 zusammen. Die AllowEncodedSlashesEinstellung wird nicht von virtuellen Hosts geerbt, und virtuelle Hosts werden in vielen Standard-Apache-Konfigurationen verwendet, z. B. in Ubuntu. Die Problemumgehung besteht darin, die AllowEncodedSlashesEinstellung in einem <VirtualHost>Container ( /etc/apache2/sites-available/defaultin Ubuntu) hinzuzufügen .

Fehler 35256 : %2Fwird in PATH_INFO dekodiert (Dokumentation AllowEncodedSlashesbesagt , dass keine Dekodierung durchgeführt wird)

Fehler 46830 : Wenn AllowEncodedSlashes Onim globalen Kontext festgelegt, wird es nicht von virtuellen Hosts geerbt. Sie müssen AllowEncodedSlashes Onin jedem <VirtalHost>Container explizit festlegen .

In der Dokumentation zum Zusammenführen der verschiedenen Konfigurationsabschnitte heißt es:

Abschnitte innerhalb von <VirtualHost>Abschnitten werden nach den entsprechenden Abschnitten außerhalb der Definition des virtuellen Hosts angewendet. Dadurch können virtuelle Hosts die Hauptserverkonfiguration überschreiben.

Ich bin immer wieder auf diesen Beitrag für ein anderes Problem gestoßen. Lassen Sie mich das ganz schnell erklären.

Ich hatte die gleiche Stil-URL und versuchte auch, sie zu vertreten.

Beispiel: Proxy-Anforderungen von /example/einem anderen Server.

/example/http:%2F%2Fwww.someurl.com/

Problem 1: Apache glaubt, dass dies eine ungültige URL ist

Lösung: AllowEncodedSlashes Onin httpd.conf

Problem 2: Apache dekodiert die codierten Schrägstriche

Lösung: AllowEncodedSlashes NoDecodein httpd.conf (erfordert Apache 2.3.12+)

Problem 3: mod_proxy versucht, die URL, die sich %2Fin %252F(z. B. /example/http:%252F%252Fwww.someurl.com/) ändert, neu zu codieren (doppelt zu codieren) .

Lösung: httpd.confVerwenden Sie das ProxyPassSchlüsselwort nocanon, um die unformatierte URL über den Proxy zu übergeben.

ProxyPass http://anotherserver:8080/example/ nocanon

httpd.conf Datei:

AllowEncodedSlashes NoDecode

<Location /example/>
  ProxyPass http://anotherserver:8080/example/ nocanon
</Location>

Referenz:

• http://httpd.apache.org/docs/2.2/mod/mod_proxy.html
• http://www.silverdisc.co.uk/blog/2009/02/28/url-canonicalisation-and-normalisation
• % 2F in mod_rewrite kann nicht übereinstimmen

Ich habe auch sehr viele Stunden mit diesem Problem verschwendet. Ich bin etwas spät zur Party, aber es scheint, dass es jetzt eine Lösung gibt.

Gemäß diesem Thread gibt es (gab) einen Fehler in Apache AllowEncodedSlashes On, der den 404 verhindert, aber fälschlicherweise die Schrägstriche dekodiert , was laut RFC falsch ist.

Dieser Kommentar bietet eine Lösung, nämlich zu verwenden:

AllowEncodedSlashes NoDecode

Angesichts all der Probleme entschied ich mich für base64_encoding, gefolgt von urlencoding. Es funktioniert, ohne mit den Einstellungen des Apache-Servers herumspielen oder Fehlerberichte anzeigen zu müssen. Es funktioniert auch, ohne die URL in den Abfragebereich einfügen zu müssen.

$enc_url = urlencode(base64_encode($uri_string));

und um es zurückzubekommen

$url = base64_decode(urldecode($enc_url));

http://example.com/admin/supplier_show/8/YWRtaW4vc3VwcGxpZXJz

http://example.com/admin/supplier_show/93/YWRtaW4vc3VwcGxpZXJzLzEwMA%3D%3D

Nach einigem Testen und Betrachten des Fehlers in Apache bin ich zu dem Schluss gekommen, dass dies trotz angebotener Lösungen in verschiedenen Foren ein ungelöstes Problem in Apache ist. Siehe den Fehler: https://issues.apache.org/bugzilla/show_bug.cgi?id=35256

Die Problemumgehung, die für mich funktioniert, besteht darin, den URI so umzugestalten, dass sich das Element, das die maskierten Schrägstriche enthalten kann, im Abfrageabschnitt des URI anstelle des Pfads befindet. Meine Tests zeigen, dass sie dort nicht von Apache herausgefiltert werden, unabhängig von den Einstellungen AllowEncodedSlashes und AcceptPathInfo.

Damit: http://test.com/url?http%3A%2F%2Fwww.url2.com

oder: http://test.com/url?theURL=http%3A%2F%2Fwww.url2.com

anstatt: http://test.com/url/http%3A%2F%2Fwww.url2.com

Dies bedeutet eine Änderung der Architektur für unser Projekt, die jedoch unvermeidlich erscheint. Ich hoffe, Sie haben eine Lösung gefunden.

Ersetzen Sie %2Fdurch %252Fauf der Client-Seite.

Dies ist die doppelt codierte Form des Schrägstrichs.

Wenn es den Server erreicht und vorzeitig dekodiert wird, wird es in% 2F dekodiert, was genau das ist, was Sie wollen.

Ich habe das gleiche Problem mit "AllowEncodedSlashes On" und habe versucht, die Direktive an verschiedenen Stellen zu platzieren: apache2.conf, httpd.conf und in einem Abschnitt, wie in einem Beispiel unter http: //www.jampmark angegeben .com / web-scripting / 5-Lösungen-zu-URL-codierten-Schrägstrichen-Problem-in-Apache.html .

Wenn Sie dies noch nicht getan haben, möchten Sie möglicherweise Ihre Protokollierungsstufe auf Debug (eine andere Anweisung) setzen und prüfen, ob der Fehler angezeigt wird:

% 2f (codiert '/') in URI (decodiert = '/ url / http: //www.url2.com') gefunden und 404 zurückgegeben

Andere nicht gefundene Fehler geben diese Informationen nicht in den Protokollen an. Nur eine weitere Diagnose ...

Viel Glück (an uns beide)!