Изображение://wp-content/uploads/2012/08/wordpress 404 page.gif[изображение, название = "wordpress 404 page", ширина = 235, высота = 235]
Этот баг раздражает меня очень долго. В WordPress после обновления или сохранения нового поста или существующего поста иногда он перенаправляется на страницу 404, и это происходит случайным образом, не имея понятия, что является причиной, вызвавшей корень.
После прочтения несколько похожих постов -
this
и
http://wordpress.org/support/topic/clicking-update
-page-results-in-a-404[это], я обнаружил, что это происходит из-за фильтрации
mod__security
, установленной в Apache - если сообщение содержит определенную заранее определенную опасную« комбинацию слов », такую как« exec »или« SQL » «Вставить команды», например «вставить», пост будет отфильтрован, а WordPress просто вернет страницу 404.
Вот мое решение:
1. Отключено mod__security
Многие предлагают отключить модуль
mod__security
, добавив следующие правила в` .htaccess`.
#... <IfModule mod__security.c> SecFilterEngine Off SecFilterPost Off </IfModule> <IfModule mod__env.c> SetEnv MODSEC__ENABLE Off PassEnv MODSEC__ENABLE </IfModule> #...
К сожалению, вышеупомянутое решение не работает для меня. Копаясь в
httpd.conf
, выясняю, что мой Apache использует последний` mod__secuirty2`, затем я снова пытаюсь следовать следующему правилу:
#... <IfModule mod__sec2.c> SecFilterEngine Off SecFilterPost Off </IfModule> #...
Но тоже не работает. Вы можете попытать счастья :)
2. Обойти правила mod__security
После поиска в Google, убедитесь, что «mod__security 2» больше не поддерживает переопределения «.htaccess», вам нужно обойти эти правила вручную через файл конфигурации.
Чтобы исправить это, найдите us
/usr/local/apache/conf/modsec2/exclude.conf
и добавьте содержимое ниже в начале файла.
/usr/local/apache/conf/modsec2/exclude.conf
<locationmatch "/wp-admin/post.php"> SecRuleRemoveById 300013 SecRuleRemoveById 300015 SecRuleRemoveById 300016 SecRuleRemoveById 300017 </locationmatch>
WordPress использует
/wp-admin/post.php
для обновления сообщения, теперь` mod__security` будет обходить правила - 300013, 300015, 300016, 300017
Перезапустите сервер Apache. Обновите предыдущую проблему-пост снова, теперь она успешно обновлена, больше не перенаправляйте на страницу 404, она работает!
3. Какой идентификатор правила фильтровать?
Подождите, как мы узнаем, какие правила фильтровать? Вы можете найти эту информацию в
modsec__audit.log
- все отфильтрованные или перехваченные URL будут зарегистрированы в этом файле.
/usr/local/apache/logs/modsec__audit.log
# your problem-post URL here... --2950df1e-H-- Сообщение: доступ запрещен с кодом 500 (фаза 2). Сопоставление с образцом "((выберите | предоставить | удалить | вставить | удалить | изменить | заменить | усечь | обновить | создать | переименовать | описать)[[: space:]]+[A-Z | a-z | 0-9 | \ \ ** | | \\,]+[[: пространство:]]+ (с | в | таблице | базы данных | Индекс | вид)[[: пространство:]]+[A-Z | а-г | 0-9 | \\ ** | | \\,]| UNION SELECT. ** \\ '. ** \\'. ** ,[0-9]. ** INTO. ** FROM) "в REQUEST__BODY. [file "/usr/local/apache/conf/modsec2.user.conf"][line "345"][id "300013"][rev "1"] [msg "Generic SQL injection protection"][severity "CRITICAL"] Действие: Перехвачено (фаза 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 yourhttp.conf
,mod__security
logs may have logged the error messages to somewhere else, do consult your hosting provider for detail.
References
-
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