1

我已经实施了一个自定义主体方法，如第 5 步中所述：使用自定义主体

然后，我从数据库中检索用户凭据以与自定义主体一起使用，但这会导致对每个请求的数据库调用，因此答案自然是将我的用户对象保存在某个位置，会话或缓存。

但是，似乎HttpContext.Current.Session无法从内部访问 Application_OnPostAuthenticateRequest，因此 Cache 似乎是要走的路

问题是这里和这里的这两个答案提供了相互矛盾的建议。第一个建议

不，不要使用 HttpCurrent.Current.Cache 来存储用户特定的信息，因为缓存对所有用户都是通用的，你会遇到冲突。请改用 HttpContext.Current.Session，因为这将特定于用户。

第二个建议

使用缓存而不是会话

那么哪个是首选方法？
如果Session是要走的路，我如何将我的用户对象从Application_OnPostAuthenticateRequest方法中放入 Session 对象中。
如果Cache是前进的道路，我将面临什么问题？例如，缓存中的项目是否有时间限制？（我知道通过使用来自用户对象的唯一键来解决潜在的冲突）

4

1 回答 1

3

不确定您是否仍在寻找答案，但在Ticket.UserData写票时存储身份验证信息的最佳位置是在属性中。

我假设如果您使用的是自定义提供程序，那么您将覆盖该SetAuthCookie方法。

如果是这种情况，那么该方法将让您传递额外的信息以进行存储。存储友好的用户名、角色或其他身份验证详细信息等内容很常见。

请参阅此链接以在身份验证 Cookie 中设置 UserData

于 2012-10-17T14:19:19.403 回答