Question

乍一看这似乎与this question非常相似，但在我的情况下，我已经在我的MVC应用程序中实现了基于标准AspNetSqlMembershipProvider的安全性。

当我在localhost或内部登台服务器上部署我的应用程序时，一切都按预期工作 - 大多数HomeController和AccountController操作对未经身份验证的用户可见，而所有其他操作都受到保护（我使用[Authorize]属性标记需要保护的类和方法）

问题在于，当我将我的应用程序部署到实时托管服务器时，基本上所有请求都被重定向到登录页面而没有任何明显的原因。

我意识到我必须忽略一些简单但关键的配置，但由于我是这个整个.NET的新手（更别关注ASP和MVC）我不能为我的生活弄清楚什么是错的或者丢失

如果需要更多信息，请告诉我，我很乐意提供。

编辑： Web.config中没有<location>个元素。此外， staging 与 live 站点Web.config的差异仅在连接字符串和Elmah记录器配置中。

此外，注册全局过滤器的代码非常标准（我没有触及过这个）：

public static void RegisterGlobalFilters(GlobalFilterCollection filters)
{
    filters.Add(new HandleErrorAttribute());
}

服务器配置中是否存在可能导致不同行为的内容？我应该在哪里看？

Answer 1

事实证明，这个问题确实是一个“琐碎的配置问题”，尽管它与asp.net或mvc无关。

在我的托管服务提供商的控制面板中，我只需授予匿名用户权限即可从应用程序的物理文件夹中读取文件。

完成此操作后，应用程序代码按预期工作。

似乎由于匿名（未经身份验证的）用户对物理文件系统中的任何内容都没有读取权限，因此将IIS解释为401错误并自动将所有请求重定向到已配置的登录方法（设置为“表单”），导致这个看似奇怪的错误信息。