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場上的實際網站（容易出現高負載）可能更合適。這種設置的分離有利於單獨的網站。

我認爲，出於可擴展性的原因，您應該考慮分離問題，但是如果可能或不可能，它們全都取決於應用程序的設計。我們正在爲特定類型的網站構建一個框架，這意味着設計的實際實施不同於每個客戶，但我們需要一種標準化的方式來管理網站，因此這是我們的合理選擇。