TOC

WordPress-Anzeige 404 nach der Aktualisierung des Beitrags?

image

Dieser Fehler nervt mich schon sehr lange. In WordPress wird nach dem Aktualisieren oder Speichern eines neuen Beitrags oder eines vorhandenen Beitrags dieser irgendwann auf eine 404-Seite umgeleitet, und dies geschieht zufällig.

Nach ein paar ähnlichen Beiträgen lesen - this und http://wordpress.org/support/topic/clicking-update -page-results-in-a-404[this], ich finde, das liegt an der auf Apache installierten `mod__security'-Filterung - Wenn ein Beitrag bestimmte vordefinierte gefährliche" Wortkombinationen "wie" exec "oder" SQL "enthält Einfügen von Befehlen wie "Einfügen", der Beitrag wird gefiltert und WordPress gibt nur eine 404-Seite zurück.

Hier ist meine Lösung:

1. mod__security deaktiviert

Viele schlagen vor, das Modul "mod__security" zu deaktivieren, indem Sie die folgenden Regeln in ".htaccess" festlegen. 

#...
<IfModule mod__security.c>
SecFilterEngine Off
SecFilterPost Off
</IfModule>

<IfModule mod__env.c>
SetEnv MODSEC__ENABLE Off
PassEnv MODSEC__ENABLE
</IfModule>
#...

Leider funktioniert die obige Lösung nicht für mich. Wenn Sie in httpd.conf einsteigen, finden Sie heraus, dass mein Apache aktuelles mod__secuirty2 verwendet. Dann versuche ich die folgende Regel erneut: 

#...
<IfModule mod__sec2.c>
SecFilterEngine Off
SecFilterPost Off
</IfModule>
#...

Aber auch nicht funktionieren. Du kannst dein Glück versuchen :)

2. Umgehen der mod__security-Regeln

Stellen Sie nach dem Googeln fest, dass "mod__security 2" keine Überschreibungen für ".htaccess" mehr unterstützt. Sie müssen diese Regeln manuell über die Konfigurationsdatei umgehen.

Um dies zu beheben, suchen Sie nach "/usr/local/apache/conf/modsec2/exclude.conf" und fügen Sie den Inhalt am Anfang der Datei an.

/usr/local/apache/conf/modsec2/exclude.conf 

<locationmatch "/wp-admin/post.php">
SecRuleRemoveById 300013
SecRuleRemoveById 300015
SecRuleRemoveById 300016
SecRuleRemoveById 300017
</locationmatch>

WordPress verwendet /wp-admin/post.php , um den Beitrag zu aktualisieren. Mod__security umgeht jetzt die Regeln - 300013, 300015, 300016, 300017.

Starten Sie den Apache-Server neu. Aktualisieren Sie das vorherige Problem erneut, es wurde jetzt erfolgreich aktualisiert, keine Weiterleitung auf 404-Seite, es funktioniert!

3. Welche Regel-ID soll gefiltert werden?

Warten Sie, woher wissen wir, welche Regeln gefiltert werden sollen? Sie finden diese Informationen in modsec__audit.log . - Alle gefilterten oder abgefangenen URLs werden in dieser Datei protokolliert.

/usr/local/apache/logs/modsec__audit.log 

# your problem-post URL here...

--2950df1e-H--

Nachricht: Zugriff mit Code 500 (Phase 2) verweigert. Musterübereinstimmung "((Wählen Sie | Gewähren | Löschen | Einfügen | Ablegen | Ändern | Ersetzen | Abschneiden | Aktualisieren | Erstellen | Umbenennen | Beschreiben)[[: Leerzeichen]]+[A-Z | A-Z | 0-9 | \
\ **  | | \\,]+[[: space:]]+ (von | in | tabelle | datenbank | index | view)[[: space:]]+[A-Z | a-z | 0-9 | \\ **  | | \\,]| UNION SELECT. **  \\ '. **  \\'. ** ,[0-9]. **  INTO. **  FROM) "bei REQUEST__BODY.

[file "/usr/local/apache/conf/modsec2.user.conf"][line "345"][id "300013"][rev "1"]

[msg "Generic SQL injection protection"][severity "CRITICAL"]

Aktion: Abgefangen (Phase 2)

# ...

Filter by URL or your IP, to identify which rules are triggered when you update the post. In the above case, the post’s URL hits rule “ 300013 “, and you need to bypass this rule id in order to update the post.

  • Note**
    Check your http.conf , mod__security logs may have logged the error messages to somewhere else, do consult your hosting provider for detail.

References

  1. http://www.modsecurity.org/blog/archives/2007/12/using transacti.html[Using Transactional Variables Instead of SecRuleRemoveById]. 404 error after editing update post . Clicking update page result in a 404 . WordPress error 404 when publishing or saving post . WordPress mod security 2 . Weird 500 internal server error on WordPress resolved 404 mod__security wordpress

Related