2012-03-12 55 views
6

我使用FormsAuthentication,但我添加了一個自定義MemberShipProvider以根據自定義用戶表進行驗證。維護用戶標識(MVC)的最佳實踐

所有包含「用戶數據」的表都有一個idUser列,所以我需要維護用戶ID以向用戶顯示其數據。

以前我使用過一個會話變量(ASP.NET Webform),但是當我將MVC重寫爲web應用時,我想問一下通常認爲什麼是最好的方法。

會話變量仍然是持有idUser的最佳位置,或者我應該添加一個自定義的「Current.User.Identity」,除了用戶名還包含一個public userId?

或者我應該選擇完全不同的方法?

回答

3

當我爲MVC實現自定義成員資格提供程序時,我遇到了同樣的問題。我最終做了兩件事。我將用戶的Id存儲在MembershipUser對象的ProviderUserKey字段中。見provideruserkey。然後回答你的問題,是的,我從System.Web.Security.IPrincipal創建了一個自定義主體,儘管我之後繼承自System.Web.Security.RolePrincipal,因爲我希望支持角色。

public class MyPrincipal : RolePrincipal 
{ 
    public Guid Id { get; set; } 

    public MyPrincipal(string providerName, IIdentity identity, Guid id) : base(identity) 
    { 
     Id = id; 
    } 
} 

更新:我不想在我的情況下使用會話的原因是因爲我已經停用了該應用程序。我已經讀過,MVC背後的核心概念是關注點的分離,並且這與網絡的工作方式密切相關,這是無狀態的。儘管我不記得自己現在讀的那些東西,但我現在還記得。不過,我還記得,如果你可以消除會話,你應該這樣做。它將允許IIS提供來自應用程序的同時請求,而不必等待一個請求完成(並釋放用戶會話),然後下一個請求才能使用會話併發送響應。其中最大的影響是使用Ajax加載頁面內容。

+0

謝謝!我正在考慮類似的方法。雖然我贊同@Mark S.上面的說法,但最簡單的是使用會話對象。 – Kman 2012-03-12 22:56:56

+0

增加了爲什麼我避開了會議的細節 – 2012-03-12 23:00:10

+0

會議不一定是邪惡的,可能是必要的。通常我會看到用戶禁用會話,並開始過度依賴Cookie來增加每個HTTP請求的大小。另一種同時處理請求的方法是使用異步控制器,這在MVC4測試版中非常簡單,並且可以在以前的版本中完成一些小工作。 – Mark 2012-03-12 23:08:25

3

是你的用戶名獨特的嗎?如果是這樣,則不需要維護UserId,因爲您可以簡單地通過用戶名檢索用戶。

我的MVC項目已經實現了成員身份,與傳統的Web窗體應用程序非常相似。我認爲除非你試圖構建一個無狀態的REST類型的應用程序,否則沒有任何理由去看兩者。你是如何在Web Forms中維護你的UserId的?會議?然後在MVC中使用會話。沒有理由重新發明輪子。

當然,如果你有其他改變的原因,有很多方法來存儲UserId。您可以將其存儲在身份驗證Cookie的UserData中。您也可以創建自己的身份驗證票證,該票證使用UserId作爲密鑰而不是用戶名。你甚至可以創建一個Custom Principal來存儲一些額外的信息。

您可能想要檢討Forms Authentication Configuration and Advanced Topics。本文將介紹在身份驗證票證中存儲附加數據(UserId)並創建自定義主體。這兩種方法都可能符合您的要求。

+0

用戶名是唯一的,但我需要userId,因爲這是我的模型(數據庫)中的標識列。所以從我需要查詢它的表中獲取數據...其中userid = idUser。我會看看你提供的鏈接:) – Kman 2012-03-12 22:43:24

+0

會話是最簡單,最快捷的方式來維護你的UserId。 MVC的使用當然不排除會話的使用。我的2美分,使用會話。 – Mark 2012-03-12 22:50:49

+0

我同意。它在我的webform應用程序中運行的很好。我主要擔心的是,在MVC中,這種方法是「過時的」。再次感謝!:) – Kman 2012-03-12 22:59:08