爲什麼asp.net成員資格UserID未存儲在身份驗證票證中？

我一直在尋找通過存儲我的用戶ID（INT）在身份驗證Cookie（Storing and accessing a legacy UserID in asp.net membership）的區域的UserData我自己的用戶錶鏈接到asp.net成員。因爲我的應用程序是爲了我自己的使用，也是爲了幫助我學習asp/c＃，所以我認爲比較調整成員資格以適應我的數據庫和反向工作可能是一個不錯的主意（即，使用成員資格退出該框並相應地調整我的數據庫）。爲什麼asp.net成員資格UserID未存儲在身份驗證票證中？

如果將我的數據庫使用GUID（唯一標識符），用戶ID爲我所有與用戶相關的表的外鍵，那麼我還需要一種方法，使用戶ID容易接觸到我的應用程序。接受的方式來獲得用戶名似乎是像這樣：

Guid userID = (Guid)Membership.GetUser().ProviderUserKey;

現在，如果我理解正確的話，這涉及到數據庫的讀取。也許我很挑剔，但在每個請求上似乎都沒有必要。我會傾向於把它放在票上。我無法看到在票證（guid或int）中添加PK值時出現任何問題。是否存在安全風險？成員似乎很高興使用UserName作爲關鍵字而不是代理。這引出了問題 - 爲什麼他們不把用戶ID放在票證中？

來源

2012-02-15 Fruitbat

你可以使用你的INT-ID的使用GUID的鏈接，例如自定義成員資格提供：http://stackoverflow.com/questions/6532418/how-to-combine-using-membership-api-with-own - 應用相關的數據/ 6532611＃6532611 – 2012-02-15 15:41:39

@TimSchmelter - 這是本質上，我在做什麼。我只是想知道爲什麼具有開箱即用成員資格的用戶標識未存儲在認證工單中。他們忘記了還是有理由不把它放在那裏。 – Fruitbat 2012-02-15 15:55:56

Cookies和網址有實際最大長度 - 在FormsAuthenticationTicket.UserData文檔狀態：

「你應該限制存儲在的UserData屬性的數據量您必須確保的UserData屬性的大小呢在Cookie無效或過長的URL不會導致「。

ASP.NET可以配置爲使用cookieless forms authentication，它將認證票證存儲在URL中。在這種情況下，ASP.NET ISAPI篩選器還必須執行一些額外的工作來清除票據信息，然後重寫URL。

所以部分原因可能是由於保持默認cookie/URL長度最小的折衷 - 在票證中存儲加密的，序列化的Guid將增加cookie/URL的長度，並且還可以進一步限制（不會太多）可以存儲在UserData中的數據量。

來源

2012-02-15 21:24:30 kuujinbo

這似乎至少是合理的。當然，如果用戶名是唯一的，它將涵蓋顯示名稱和數據庫密鑰的功能。儘管據我所知，用戶名的唯一性不是數據庫約束，而是在CreateUser存儲過程中進行檢查。 – Fruitbat 2012-02-20 07:56:49

是的，困惑爲什麼用戶名不是*表*約束。我認爲會員提供商是有意編寫的，以平衡可擴展性和靈活性。因爲微軟希望開發者在需要的時候推出他們自己的提供商，所以這些功能可能被排除在API之外。沒有人會對MS表示讚賞;但是，恕我直言，他們做了一個非常糟糕的工作。在我以前的工作中，我做了*真正的開發工作，並大量使用'UserId'（正如你打算的那樣）。除了編寫提供程序之外，還創建了一個靜態助手類，其中包含一些方法，其中包括緩存的'UserId'。 – kuujinbo 2012-02-21 09:02:19

你總是可以編寫自己的UserPrinciple實施IPrinciple，可以給你，一旦用戶ID，這可以在任何地方應用程序調用，而無需實際命中數據庫。然後你可以在cookie中使用userId，如果你仍然想。

來源

2012-02-15 21:30:55 Bilal

當然，我可以但我認爲你已經錯過了這個問題。 – Fruitbat 2012-02-20 07:58:36

爲什麼asp.net成員資格UserID未存儲在身份驗證票證中？

回答

相關問題