Sonderzeichen in der URL führen dazu, dass die benutzerdefinierte Weiterleitung fehlschlägt

Sonderzeichen in der URL führen dazu, dass die benutzerdefinierte Weiterleitung fehlschlägt

Ich habe eine Domain, auf der ich versuche, benutzerdefinierte Weiterleitungen für die Fehlerseiten einzurichten.
Meine .htaccessDatei sieht folgendermaßen aus:

RewriteEngine On
AddDefaultCharset UTF-8
DefaultLanguage en-US
# disable TRACK and TRACE http methods. 'RewriteEngine On' is required!
RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK|OPTIONS|HEAD|PUT|DELETE)
RewriteRule .* - [F]
Options All -Indexes
ServerSignature Off
<ifModule mod_headers.c>
        Header unset X-Powered-By
</ifModule>
<Files .htaccess>
order allow,deny
deny from all
</Files>
<IfModule php5_module>
        php_value session.cookie_httponly true
        #php_value session.cookie_secure true
</IfModule>
RewriteCond %{QUERY_STRING} _escaped_fragment_=(.*)
#to block all links to '.gif', '.jpg','.js' and '.css'  files which are not from the domain name 'http://www.example.com/'
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://(www\.)?example.com/.*$ [NC]
RewriteRule \.(gif|jpg|css|js)$ - [F]
#to deny requests containing invalid characters
RewriteBase /
RewriteCond %{THE_REQUEST} !^[A-Z]{3,9}\ [a-zA-Z0-9\.\+_/\-\?\=\&]+\ HTTP/ [NC]
RewriteRule .* - [F,NS,L]

# Secure directories by disabling execution of scripts
AddHandler .php .pl .py .jsp .asp .htm .shtml .sh .cgi
Options -ExecCGI


#Error page handeller
ErrorDocument 400 /htaccessSample/errordocs/error-code.php
ErrorDocument 401 /htaccessSample/errordocs/error-code.php
ErrorDocument 403 /htaccessSample/errordocs/error-code.php
ErrorDocument 404 /htaccessSample/errordocs/error-code.php

Wenn ich in die URL etwas wie folgt eingebe:

  • example.com/aboutUs: Alles funktioniert normal.
  • example.com/xxygsds: Die URL wird auf die benutzerdefinierte 404-Fehlerseite umgeleitet.
  • example.com/<>: Dies leitet auf die verbotene 403-Seite weiter. Die Weiterleitung erfolgt jedoch auf die apache/error/HTTP_FORBIDDEN.html.varSeite und nicht auf die benutzerdefinierte Seite, wie oben erwähnt.

Meine Fragen:
1. Warum erfolgt diese Weiterleitung?
2. Wie kann ich unter allen Umständen eine Weiterleitung auf die benutzerdefinierte 403-Fehlerseite einrichten?

Antwort1

Ich bin mir nicht sicher, warum das passiert. Ich habe das gleiche Problem mit meiner 403-Seite. Wenn Sie eine bestimmte 403-Seite umleiten möchten, verwenden Sie Folgendes:

<Files some_thing> 
order Deny,Allow 
Deny from all 
</Files>

Antwort2

Versuchen Sie, die Speicherorte Ihrer Fehlerdokumente an den OBEN-Punkt Ihrer .htaccess-Datei zu verschieben. Ich habe mir Ihr Beispiel eine Weile angesehen, um herauszufinden, was passiert ist, und dann schließlich festgestellt, dass dem Ding in diesem Fall gesagt wird, dass es beendet werden soll, bevor ihm gesagt wird, wohin es beendet werden soll.

Apache liest die Anweisungen der Reihe nach und wird im Fall L beendet. Das L ist implizit in F enthalten:

Bei der Verwendung von [F] wird ein [L] impliziert, d. h. die Antwort wird sofort zurückgegeben und es werden keine weiteren Regeln ausgewertet. https://httpd.apache.org/docs/2.4/rewrite/flags.html

Ich vermute also, dass Apache einfach nie zu diesem Satz von Anweisungen gelangt, wenn es auf die wahre, passende Groß-/Kleinschreibung Ihres <>-Beispiels stößt. Dadurch wird die Seite an die standardmäßige Apache-403-Fehlerseite gesendet, da sie beendet wurde, bevor sie diese Deklarationen erreichte. Ihre 404 hat funktioniert, weil sie nie eine der Regeln ausgelöst hat, die eine L-Bedingung enthalten, d. h. das letzte auszuführende Element, und so das Ende der htaccess-Regeln erreicht hat.

Ich bin noch nie in diese Situation geraten, weil ich die Standardfehlerseiten aus Gewohnheit immer OBEN auf die Direktive setze, zusammen mit anderen grundlegenden Dingen wie PHP-INI-Anpassungen usw.

Die Neufassungen kommen nach unten.

Das Ziel ist, dass alles, was Sie Apache mitteilen wollten, Apache mitgeteilt wurde, wenn es den L-Fall für eine Neuschreibung oder das Ende der htacess/config-Regeln erreicht. Wenn es nicht htaccess wäre, hätte Apache alle Regeln gekannt, als es mit der Bereitstellung Ihrer Site begann, aber mit htacess liest es sie meiner Meinung nach einfach und tut, was die Datei ihm sagt.

Ich glaube, das ist richtig, aber ich bin mir nicht 100 % sicher, da ich immer die Sachen, die oben stehen sollten, oben platziert habe und daher Ihren Fall nie ausgelöst habe. Der Schlüssel ist, zu erkennen, dass L, Last, wirklich Last bedeutet, und dann auch zu wissen, dass F L impliziert.

Generell lohnt es sich, beim Umgang mit Apache-Konfigurationen organisiert vorzugehen:

# top generics etc
#Error page handler
ErrorDocument 400 /htaccessSample/errordocs/error-code.php
ErrorDocument 401 /htaccessSample/errordocs/error-code.php
ErrorDocument 403 /htaccessSample/errordocs/error-code.php
ErrorDocument 404 /htaccessSample/errordocs/error-code.php

AddDefaultCharset UTF-8
DefaultLanguage en-US
# Disable Directory Browsing, not related to rewrite
Options All -Indexes

# Secure directories by disabling execution of scripts
AddHandler .php .pl .py .jsp .asp .htm .shtml .sh .cgi
Options -ExecCGI

ServerSignature Off
<ifModule mod_headers.c>
        Header unset X-Powered-By
</ifModule>

<IfModule php5_module>
        php_value session.cookie_httponly true
        #php_value session.cookie_secure true
</IfModule>

<Files .htaccess>
order allow,deny
deny from all
</Files>

## NOW do the set of rewrite rules, everything that apache needs to 
## know has been told to it by this point
RewriteEngine On
# disable TRACK and TRACE http methods. 'RewriteEngine On' is required!
RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK|OPTIONS|HEAD|PUT|DELETE)
RewriteRule .* - [F]

RewriteCond %{QUERY_STRING} _escaped_fragment_=(.*)
#to block all links to '.gif', '.jpg','.js' and '.css'  files which are not from the domain name 'http://www.example.com/'
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://(www\.)?example.com/.*$ [NC]
RewriteRule \.(gif|jpg|css|js)$ - [F]
#to deny requests containing invalid characters
RewriteBase /
RewriteCond %{THE_REQUEST} !^[A-Z]{3,9}\ [a-zA-Z0-9\.\+_/\-\?\=\&]+\ HTTP/ [NC]
RewriteRule .* - [F,NS,L]

Denken Sie daran, am Ende Ihrer .htaccess-Datei immer eine neue Zeile/einen Zeilenumbruch einzufügen. Ihre Version ist extrem zufällig und unorganisiert, was meiner Meinung nach die eigentliche Ursache Ihrer Probleme ist. Wenn Sie sich einfach daran gewöhnen, Ihre Regeln klar und konsistent anzuordnen (d. h., Umschreibungen werden nicht mit anderen Regeln vermischt), werden Sie die Arbeit mit Apache im Allgemeinen viel einfacher finden.

verwandte Informationen