可能的mod_重写与.htaccess（WordPress）中请求后保护代码的位置冲突

为了增加安全性，我尝试使用以下.htaccess代码阻止基于成员身份的WordPress网站上的非标准POST请求：

# Block non-standard POST requests
RewriteCond %{REQUEST_METHOD} POST [NC]
RewriteCond %{REQUEST_URI} !^.*/wp-admin/ [NC]
RewriteCond %{REQUEST_URI} !^.*/wp-cron.php [NC]
RewriteCond %{REQUEST_URI} !^.*/wp-login.php [NC]
RewriteCond %{REQUEST_URI} !^.*/sign-in/ [NC]
RewriteRule ^(.*)$ - [F]

RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]

# Block non-standard POST requests
RewriteCond %{REQUEST_METHOD} POST [NC]
RewriteCond %{REQUEST_URI} !^.*/wp-admin/ [NC]
RewriteCond %{REQUEST_URI} !^.*/wp-cron.php [NC]
RewriteCond %{REQUEST_URI} !^.*/wp-login.php [NC]
RewriteCond %{REQUEST_URI} !^.*/sign-in/ [NC]
RewriteRule ^(.*)$ - [F]

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

通过最后一个条件，/sign-in/页面被“白名单”，因为它是站点成员登录时向其发出所有POST请求的指定URL：

我发现该代码仅在放置在默认WordPress.htaccess代码中时有效（即，通过重写条件成功阻止所有未列入白名单的POST请求）：

# Block non-standard POST requests
RewriteCond %{REQUEST_METHOD} POST [NC]
RewriteCond %{REQUEST_URI} !^.*/wp-admin/ [NC]
RewriteCond %{REQUEST_URI} !^.*/wp-cron.php [NC]
RewriteCond %{REQUEST_URI} !^.*/wp-login.php [NC]
RewriteCond %{REQUEST_URI} !^.*/sign-in/ [NC]
RewriteRule ^(.*)$ - [F]

RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]

# Block non-standard POST requests
RewriteCond %{REQUEST_METHOD} POST [NC]
RewriteCond %{REQUEST_URI} !^.*/wp-admin/ [NC]
RewriteCond %{REQUEST_URI} !^.*/wp-cron.php [NC]
RewriteCond %{REQUEST_URI} !^.*/wp-login.php [NC]
RewriteCond %{REQUEST_URI} !^.*/sign-in/ [NC]
RewriteRule ^(.*)$ - [F]

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

但是，如果POST阻止代码位于WordPress.htaccess代码的上方或下方，则/sign-in/条件不起作用。如果代码位于WordPress默认代码之上，则通过403阻止对/sign-in/页面的POST请求（尽管有趣的是，对/wp-login.php的POST请求没有被阻止）。如果代码放在WordPress默认代码的下面，则不会阻止任何内容。插件开发人员告诉我，登录过程会检查$\u POST值，因此，如果POST请求没有实际发出，它将不起作用（我最初的想法是，/sign-in/URL没有被识别为POST请求）

我还被告知，这不是预期的行为，无论POST-blocking代码放在.htaccess文件中的什么位置，它都应该正常工作。有人认为可能是某些独特的服务器配置导致了这种行为。然而，我已经在几个不同的Apache服务器/主机帐户（包括精简的WordPress安装）上测试了这个问题，并且得到了相同的结果

我想了解这种行为的原因。我想这可能与重写规则和/或被处理的方式有关，但我还没能提出任何具体的想法来进行测试。我还检查了错误日志，甚至尝试启用，但据我所知，没有发现任何有价值的东西