在 .NET 中强制创建 HttpContext.Current.Session
我正在开发一个使用 .NET 的 StaticFileHandler 来提供动态生成的内容的应用程序... 我们的应用程序还有另一部分使用当前的 HttpSession 来存储用户特定的数据。
由于 StaticFileHandler 设计用于处理静态文件,因此它不实现 IRequiresSessionState,因此通过应用程序的该部分的任何内容都无法从应用程序的其余部分访问特定于会话的数据。
StaticFileHandler 是 System.Web 的内部组件,因此我不能将其扩展到我自己的也实现 IRequiresSessionState 的类中。当我检测到会话为空时,是否有其他方法可以强制创建会话?
I'm working on an application that uses .NET's StaticFileHandler to serve up dynamically generated content...
There is also another part of our application that uses the current HttpSession to store user-specific data.
Since the StaticFileHandler is designed to handle static files, it doesn't implement IRequiresSessionState, thus anything going through that part of the app doesn't have access to the session-specific data from the rest of the app.
StaticFileHandler is internal to System.Web so I can't just extend it into my own class that also implements IRequiresSessionState. Is there some other way I can force creation of the session when I detect that it's null?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
我们还有一个自定义会话提供程序,它使用一些更有效的缓存,因此我能够利用它来自己创建会话。如果其他人感兴趣的话,这是我的代码,但请注意,如果您想借用,则必须自己调整它:
难题的一大部分是有关获取 SessionStateStoreData 对象的部分。如果您使用的是默认实现,请通过 .NET 反射器了解如何访问它!
此外,这样做的一个缺点是 SessionStateModule 仅在会话实际更改后才创建 cookie。然而,通过这段代码,我被迫一直创建 cookie,即使我实际上只在极少数情况下使用会话。
We also had a custom session provider that was using some more efficient caching, so I was able to piggyback off of that to create the session myself. Here's my code if anybody else is interested, but note that you'll have to tweak it yourself if you want to borrow:
The big piece of the puzzle is the part about getting the SessionStateStoreData object. If you're using the default implementation, have fun looking through .NET reflector to figure out how to access it!
Also, one downside to this is that the SessionStateModule only creates a cookie once the session is actually changed. Going through this code, however, I'm forced to create the cookie all the time, even though I'm actually only using the session in a very rare case.