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 回答