Session_Start中的Request.RedirectToRoute導致會話重啓

在Session_Start事件中，它調用authenticate_authorize類來返回AuthResult對象。Session_Start中的Request.RedirectToRoute導致會話重啓

public AuthResult 
 
{ 
 
    public enumAuthResult Result {get;set;} 
 
    public string Controller {get;set;} 
 
    public string Action {get;set;} 
 
}

如果結果不enumAuthorized，控制器和行動將返回到在session_start。然後，如果使用Request.RedirectToRoute（）路由到控制器的操作，則Session_Start將處於無限循環中。看起來RedirectToRoute（）總是重新啓動會話。相反，如果使用Request.Redirect（），則正常啓動適當的控制器操作。

什麼是在Session_Start事件中調用控制器動作而不使用重定向的正確方法？
我應該將Application_AuthenticateRequest和Application_AuthorizeRequest事件中的認證和授權分開嗎？
如果身份驗證和授權是在單獨的事件中完成的，如何將AuthResult對象傳遞給Session_Start事件以便它能夠正確地重定向或路由到控制器？

Response.RedirectToRoute(AuthResult.Controller, AuthResult.Action); 
 
Response.Redirect(string.Format("{0}/{1}",AuthResult.Controller, AuthResult.Action));

來源

2016-01-14 user266909

什麼叫不使用重定向在session_start事件的控制器操作的正確方法？

正確的方法是使用Authorization Filter，該選項在選擇動作後運行。微軟已經包含了一個默認的實現，AuthorizeAttribute，它爲用戶/角色提供大多數人的需求，但如果您需要制定自定義方案，則可以繼承。

AuthorizeAttribute使用IPrincipal和IUser接口，這些接口可以由任何自定義安全方案實現，並使用ASP.NET成員資格和ASP.NET身份實現。

如果您試圖將您的安全性建立在URL上，那麼幾乎不可能確保每個行動路線都將通過您的安全方案。例如，默認情況下，主頁可通過/,/Home或/Home/Index進行訪問，因此如果您的基於URL的授權僅佔用/，則用戶將能夠規避您的安全並通過/Home或/Home/Index訪問您的主頁操作。

我會建議您不要創建您自己的安全方案 - 要做到這一點需要基於您的問題沒有的經驗。相反，您應該查看MVC security overview以找到適用於您的應用程序的最佳選項，然後閱讀解釋如何實現它的教程。請注意，ASP.NET身份取代ASP.NET成員身份。

來源

2016-01-14 07:14:03 NightOwl888

謝謝。我正嘗試在早期應用程序管道（如會話啓動）中執行一次身份驗證和授權。使用Authroization Filter將迫使我用這個屬性來修飾每個控制器。我們在IIS網站下有很多應用程序。我甚至計劃在執行MVC處理程序之前編寫HttpModule來攔截站點級別的請求，以便我們可以系統地在站點級別強制執行身份驗證/授權，並防止每個應用程序開發人員在他們的應用程序代碼中執行這種平凡的任務。 – user266909

您不需要使用AuthorizeAttribute來修飾每個控制器操作。您可以將其註冊爲FilterConfig文件中的全局過濾器一次。實際上，這是推薦的方式 - 然後使用AllowAnonymous atttribute選擇性地允許部分站點不需要安全性。 – NightOwl888

Session_Start中的Request.RedirectToRoute導致會話重啓

回答

相關問題