为什么asp.net成员资格UserID没有存储在身份验证票证中？

发布时间：2020-12-16 09:36:20 所属栏目：asp.Net 来源：网络整理

导读：我通过将我的userid(int)存储在身份验证cookie( Storing and accessing a legacy UserID in asp.net membership)的UserData区域中来查看将我自己的User表链接到asp.net成员资格. 由于我的应用程序是供我自己使用,也是为了帮助我学习asp / c#,我认为比较调整

我通过将我的userid(int)存储在身份验证cookie( Storing and accessing a legacy UserID in asp.net membership)的UserData区域中来查看将我自己的User表链接到asp.net成员资格.

由于我的应用程序是供我自己使用,也是为了帮助我学习asp / c#,我认为比较调整成员资格以适应我的数据库与反向(即使用开箱即用的成员资格并调整)的努力可能是一个好主意.我的数据库相应).

如果我将我的数据库转换为在所有用户相关表中使用guid(uniqueidentifier)UserID作为外键,那么我仍然需要一种方法来使我的应用程序可以轻松访问UserID.获得UserID的可接受方式似乎是这样的：

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

现在,如果我理解正确,这涉及到数据库的读取.也许我很挑剔,但每次请求似乎都没有必要.我倾向于把它放在票中.将PK值放入票证(guid或int)时,我看不出任何问题.是否存在安全风险？使用UserName作为密钥而不是代理,成员似乎很高兴.这引出了一个问题 – 他们为什么不把UserID放入票证？

解决方法

Cookie和URL具有实际的最大长度 – FormsAuthenticationTicket.UserData文档指出：

“You should limit the amount of data stored in the UserData property.
You must ensure that the size of the UserData property does not result
in an invalid cookie or an excessively long URL.”

ASP.NET可以配置为使用cookieless forms authentication,它将身份验证票证存储在URL中.在这种情况下,ASP.NET ISAPI过滤器还必须执行一些额外的工作来剥离票证信息,然后重写URL.

因此,部分原因可能归结为将默认cookie / URL长度保持在最低限度的权衡 – 在票证中存储加密的序列化Guid会增加cookie / URL的长度,并且还会进一步限制(您可以存储在UserData中的数据量.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!