ASP.NET MVC - 管理区域或单独的Web应用程序？

Question

到现在为止，我已经使用MVC区为我的MVC应用程序，但最近我一直在反思这个由于这一事实，你不能有一个以上的配置管理部分被用于每个应用程序的表单认证。

这已成为监守在最近的一个项目，我想设置的AUTH的cookie不到期，为用户的一个问题，但我不wan't这对于管理用户。我也不希望使用用户登录页面来访问管理工具。

我正在考虑在纯解决方案中为管理工具设置一个独立的MVC项目。这对我来说似乎是最好的选择，但我想知道部署的复杂性。（目前，我在VS2008中使用Web部署项目来管理构建）。

目前有没有人使用一个单独的MVC项目的管理部分？任何陷阱？其他意见，为什么这不是一个好主意？

谢谢。

Answer 1

我总是使用一个单独的网站进行管理。但这主要是因为我的网站管理与使用完全不同，因此需要不同的布局。

另一个积极的一面是，您不必怀疑用户是否可以修改他们不应该修改的内容，因为这些部分不是内置到用户网站中的。

更新

我的意思是布局与剃刀或母版与网络表单视图引擎。

我们使用http://admin.domainname.com和http://www.domainname.com来分隔网站。很容易设置。

分离网站也使控制器和视图更清洁，因为他们只处理管理员或用户的任务。不需要很多ifs（否则如果你像我这样懒惰的编码器可以非常容易地添加:)

Answer 2

FormsAuthentication.SetAuthCookie方法允许您控制是否持续跨会话。

如果他们是管理员，请将此设置为false，否则设置为true。

有关更多信息，请参阅http://msdn.microsoft.com/en-us/library/twk5762b.aspx（第二个参数createPersistentCookie控制此选项）。

针对不同用户类别的不同登录页面，如果用户类别错误并访问错误的登录页面，则可以从身份验证方法返回false。

在设置身份验证令牌之前，所有这些逻辑都应该发生。

Answer 3

我宁愿保持给药部位分开的几个原因：

• 潜在的安全风险大大降低进入敏感区域会更容易限制和控制。
• 在一个很好的解决方案中，层（服务/数据等）之间的Separation of Concerns意味着将您的管理站点连接到主站点上可用的访问功能应该相对简单。
• 由于企业通常关注他们的前端网站，开发人员往往不太关心如何打磨他们的管理网站。这意味着影响管理网站的疏忽错误不太可能影响到主网站。
• 我使用基本控制器AuthorizeAttribute，这意味着所有操作（login！除外）都无法由外部用户访问没有适当的凭据。必要时，个人行为将被相关证书覆盖，但一般来说，这是一种“一劳永逸”的方式。虽然您可以在单站点方式中使用两个基本控制器，但我相信它的可管理性稍差。

Answer 4

表单auth cookie可能是管理区域的路径限制，但这会在处理身份验证时给您一些头痛的问题，但可能会实现。

另一种选择，而不是使用admin.hostname.com或类似的东西，是在/ admin上使用子应用程序，但是这不一定能解决你的问题。

我们将网络应用程序开发为两个不同的网站，主要是因为我们想要将管理从实际网站拆分的选项，以及可扩展性原因。我们希望能够扩大有问题的实际网站，而不是管理部分。

我们已经遇到了以下问题：

1. 内容的预览，需要一定的逻辑关系，可以将需要您存储在某种配置的网站的实际主机名，以管理员重定向到正确的网站以及处理一些安全令牌等，因为用户可能没有在网站上进行身份验证。如果您在同一个站点（相对路径和相同的身份验证），这会更容易。
2. 需要同时在多个web服务器上运行的站点（又名web farm）需要考虑到这一点。它涉及缓存失效，配置重新加载或可能在管理界面中“修改”的任何其他应用程序存储数据等内容。然而，这是任何方法都存在的问题。但是，如果您的站点直接依赖于您的Web应用程序中的任何计划工作或第三方集成，那么如果您的管理站点/系统在多个服务器上运行，则可能会导致一些问题。因此，在HA IIS故障转移群集上运行管理系统可能更合适，但在负载平衡Web场上的实际网站（容易出现高负载）可能更合适。这种设置的分离有利于单独的网站。

我认为，出于可扩展性的原因，您应该考虑分离问题，但是如果可能或不可能，它们全都取决于应用程序的设计。我们正在为特定类型的网站构建一个框架，这意味着设计的实际实施不同于每个客户，但我们需要一种标准化的方式来管理网站，因此这是我们的合理选择。