我有一个MVC程序, 宿主在windows server2008R2 的iis 7.5上 , 登录用户信息是从Cookie里读取缓存, 然后保存在 CallContext中, 后续的操作获取用户都是取CallContext, 但我发现A用户请求, 获取的登录用户信息是 B用户的, 这个概率很低, 但是一旦出错, 是很难容忍的. 请问dudu 和各位牛人 , 微软的这个CallContext是否有这个问题 , 如何解决? 感谢..
本来就不应该也不能这样保存在 CallContext 中,ASP.NET 的同一个线程本来就会被多个请求使用,请用 Session
我使用了负载均衡, 没有使用Session, 请问我能否使用HttpContext.Current.Item 来代替 . 另外 WCF 中这个 CallContext 是否安全?
@Gavin Luo: 负载均衡可以开启会话支持,不用 Session 可以用保存在 Memcached 或 Redis 中。WCF 也不安全。
@dudu: 登录信息我是保存在了Redis中, 为了避免同一个请求频繁读取 Redis 拿用户信息,也没有传递 token到后续的各个子方法中 , 所以想用 HttpContext.Current.Item 做一个请求级别的临时存储, 是否可行?
@Gavin Luo: HttpContext.Current.Items 可以,这个只对当前请求有效
@dudu: 感谢你, 如果我是想在 Task的线程中 做这种临时存储, 是否可以用 CallContext.
@Gavin Luo: 更不能使用,一次 await 就是一次线程切换
@dudu: 受教了, 如果我没有用await, 只是用Task起线程 Run 或者 Start 这种单纯的多线程操作,最后偶尔用用 Task.WaitAll(), 这种能否可以使用 ?
@Gavin Luo: 不可以使用。建议通过传参或 HttpContext.Current.Items 的方式,只要不使用 .ConfigureAwait(false)
,Task 中也可以访问 HttpContext.Current.Items
@Gavin Luo: 如果使用 ASP.NET Core ,这个问题可以轻松搞定,定义一个用于保存登录用户信息的类,用 services.AddScoped
依赖注入
dudu说的对,本来就不应该保存在CallContext中。我来蹭点豆子。
一楼正解,话说我也是来蹭豆子的!