我很難理解ASP.NET MVC中[Authorize]屬性的實際使用。根據這個概念，如果我們用[Authorize]屬性修飾控制器方法，則只有經過身份驗證的用戶纔可以訪問控制器。ASP.NET MVC中的授權屬性
我開發了一個ASP.NET MVC應用程序，沒有用[Authorize]屬性裝飾控制器。我觀察到的是，如果我在我的應用程序中使用web.config或其他方式正確實現身份驗證機制，那麼現在我可以訪問特定操作方法的URL {controller}/{action}/{id}。
系統總是要求登錄。這意味着我的控制器是安全的。我的問題是，當我可以保護我的控制器而不使用[Authorize]屬性時，那麼它的真正需求是什麼？
真正的力量來自理解和實施會員提供者與角色提供者。您可以將用戶分配到角色中，並且根據該限制，可以爲不同的用戶對控制器操作或控制器本身應用不同的訪問角色。
[Authorize(Users = "Betty, Johnny")]
public ActionResult SpecificUserOnly()
{
return View();
}
或可以根據組
[Authorize(Roles = "Admin, Super User")]
public ActionResult AdministratorsOnly()
{
return View();
}
它存在，因爲它是更方便地使用限制，也很使用屬性來標記授權參數，而不是XML配置一個完全不同的意識形態。這並不意味着打敗通用配置或任何其他授權框架，只是MVC的做法。我是這樣說的，因爲看起來你正在尋找一種技術特徵優勢，這可能不是非常方便。
BobRock已經列出了優勢。爲了增加他的答案，另一種情況是，您可以將此屬性應用於整個控制器，而不僅僅是操作，還可以將不同的角色授權參數添加到同一控制器中的不同操作以混合和匹配。
使用Authorize屬性似乎更方便，感覺更「MVC方式」。至於技術優勢有一些。
我想到的一種情況是，當您在應用中使用輸出緩存時。很好地授權屬性句柄。
另一個是可擴展性。 Authorize屬性只是開箱即用的過濾器，但您可以覆蓋它的方法並執行一些預授權操作（如日誌記錄等）。我不知道如何通過配置來完成此操作。
+1表示可擴展性。與web.config方法相比，這是一個明顯的優勢。 ;） – CptRobby
一個好處是你正在編譯訪問應用程序，所以它不會被修改Web.config的人無意中改變。
這可能對您沒有好處，並且可能是一個缺點。但對於某些訪問，它可能是可取的。
另外，我發現Web.config中的授權信息污染了它，並且使它更難找到東西。所以在某些方面，它的偏好，在其他方面沒有其他的方式來做到這一點。
使用[Authorize]屬性可以幫助防止應用程序出現安全漏洞。 MVC處理URL的方式（即將它們路由到控制器而不是實際的文件）使得通過web.config文件實際保護所有內容變得困難。
感謝answer.But相同的限制，我可以用徵收使用成員身份和角色提供對那些由控制器返回的頁面查看我的web.config。我不需要爲此使用[Authosrize]屬性。 – techmad
@kaus - 有一點需要指出的是，在MVC應用程序中使用web.config有可能造成安全漏洞。 authorize屬性考慮了所有的ASP.NET路由，而使用web.config則必須知道應用中所有可能的路由配置，並將它們考慮在內。您可能已經考慮到了這一點，但通過查看web.config和routing.config以及您看到的其他位置，您無法確定。通過查看類上的授權屬性，您知道無論路由如何，它都是安全的。 – DarrellNorton