对SEO URL的POST请求禁止

Mat*_*ttP 4 php apache mod-rewrite

我有一个基本的MVC系统,它将POST数据发送到URL等

管理/产品/添加/

但这给了我一个错误

被禁止

您无权访问此服务器上的/ admin/product/add /.

此外,尝试使用ErrorDocument处理请求时遇到404 Not Found错误.

RewriteRule很简单

RewriteRule ^(.*)/$ index.php?uri=$1
Run Code Online (Sandbox Code Playgroud)

上次我在服务器上看到这个,将文件/目录权限更改为755似乎修复了它,但这次没有.我从来没有真正理解错误的原因,所以希望有人能够提供更多信息?

reg*_*ero 9

你有2个错误:

  1. 您无权访问此服务器上的/ admin/product/add /.
  2. 此外,尝试使用ErrorDocument处理请求时遇到404 Not Found错误.

第二个肯定是同一个bug的结果.您可能在apache配置中有一些东西从默认的http服务器处理中删除404错误并将其推送到您的php应用程序,如果这个php应用程序正在运行,我们会有一个很好的404,但是......

第一个告诉你你的php应用程序根本没有运行.

所以.第一个错误告诉我们,apache确实尝试直接访问/path/to/documentroot/admin/product/add/服务器上的目录并生成它的列表(只有在获得apache授权的情况下才能完成目录内容的列表).但当然这不是您服务器上的真实目录.它是应用程序中的虚拟路径.所以apache最终得到404(导致错误2).

应用程序处理虚拟路径,apache不管理它.RewriteRule作业是 apache尝试提供它之前捕获所请求的路径,并将其index.php作为查询字符串参数提供给单个php文件().

所以...这个重写规则没有应用.可能阻止此规则应用的事情很多:

  1. mod_rewrite未激活:模块是否存在且已启用(RewriteEngine on)?
  2. 语法错误:mod重写语法很难阅读,有时真的很复杂.但这里似乎很简单.
  3. RewriteRule生成的文件可能不是apache的有效目标.如果DocumentRoot中不存在index.php文件,或者apache用户无法读取,则apache将失败.警告:拥有apache用户可读的文件意味着对文件具有读权限,但对apache用户的所有父目录也具有执行权限 .这是您的经典/ 解决方案正在解决问题的地方.chmodchown
  4. 规则必须位于有效的配置文件中.此规则是位于位置或目录部分内的apache配置文件中吗?或者可能在全局范围内 - 这可能会改变重写规则语法 - .或者它是在.htaccess文件中?如果它是.htacces,那么apache会读取.htacces文件,并且允许那里的mod重写指令(AllowOverride None).是不是有其他.htaccess文件优先?

所以要解决这个问题:

  • 如果你有一个大于2.2.16的apache版本,你可以用FallbackRessource /index.php替换RewriteRule 来检查这不是来自mod-rewrite问题.
  • 尝试直接请求index.php,以便至少对此文件的直接请求确实有效
  • 尝试直接访问 documentRoot上的有效资源(txt文件,图像,不应由重写处理但直接提供的内容)
  • 检查是否有任何虚拟路径可以映射真实的物理路径Apache不会尝试为物理路径提供服务(就像你写的那样RewriteCond %{REQUEST_FILENAME}-d)但是真正推动了index.php
  • 检查apache错误日志.
  • 使用RewriteLog调试 mod_rewriteRewriteLogLevel
  • 收集事实,设置和测试,然后将其推送到SO或Servfault.

所以问题很简单:php应用程序没有收到请求.但是有很多方法可以在这种状态下结束.消息本身并不重要.找到错误的唯一方法是检查所有参数(或者有多年的bug修复经验,并为灯泡开发一个预先认知的直觉器官 - 通常是胡子 - 就像管理员一样).我们帮助你的唯一方法是在一大堆配置细节中找到奇怪的事实,这就是为什么好的问题包含很多信息,即使所有这些信息看起来只是"经典"的.

编辑

为了澄清问题,您应该编辑您的答案,POST 使用Chrome开发工具或firebug等工具跟踪请求(保持网络跟踪记录模式以捕获多个POSTS)或尝试使用Live HTTP标头回复重播帖子.您应该尝试隔离有问题的POST并提供详细信息.调试并不神奇.

现在我知道一个神奇的随机POST失败.这是空的GET url bug.它可能是(或不).如果你有一个空的GET url隐藏在某处(例如<IMG SRC="">,url()在css中,或者标题中的空LINK).因为这些隐藏的POST在HTTP中被定义为"replay-the-request-which-initiated-the-source-page,and有些浏览器甚至会重播POST,如果他们找到了一个页面,就会给你一个页面.这可能会导致隐藏的POSTS被破坏.

也可能是POST没有发送到正确的服务器.很难说.因此,请从您的评论中收集信息,添加更多网络分析并编辑现在真正包含不充分事实的问题.