IIS7如何处理auth模块？内存范围？
作为从事过此类项目的人，您可能知道这个网站：
在本文中Mike Volodarsky 创建了一篇非常好的帖子，介绍如何为 IIS7 创建您自己的安全身份验证扩展。
我接受了这个并根据自己的需要进行了修改。我正在获取基本身份验证凭据并调用外部 Web 服务来对来自不同活动目录域的用户进行身份验证。
到目前为止，这原则上运作良好。
调用 Web 服务需要一些时间，每个请求、站点、资源（图像、样式表、javascript 文件等）都会导致 IIS7 调用模块并再次进行身份验证。
我不知道 IIS7 如何处理此模块，因此我决定创建一个基于 sql 表的安全令牌，其生命周期为 10 分钟。现在我的代码检查此令牌是否可用并授予访问权限，如果不可用，则调用 Web 服务再次进行身份验证。
我开发了一切并且运行良好。在生产中，我遇到了更严重的超时，并发现我的 sql 连接是问题所在。连接池超载。我用一个糟糕的解决方法修复了这个问题，将池大小设置为非常大的数字。
现在这是我的问题：
有谁知道这个模块是否会以任何方式保留在内存中，以便我可以在内存中存储令牌 - 应用程序池范围？这个想法是在应用程序运行时将令牌存储在内存中。但我找不到任何信息来帮助我了解该模块在 IIS7 中是如何处理的以及我的想法是否是问题的解决方案。
As those who have worked on such a project you probably know this site:
In this article Mike Volodarsky created a very good post on how to create your own security authentication extension for the IIS7.
I took this and modified to my own need. I am fetching the basic auth credentials and call an external web service to authenticate the user from a different active directory domain.
This in principal works fine so far.
Calling the web service takes some time and each request, site, resource (image, stylesheet, javascript file, etc.) causes IIS7 to call the module and authenticate again.
I am not aware how the IIS7 handles this module so I decided to create a sql-table based security token with a ten minutes lifetime. So now my code checks if this token is available and grants acccess or if not, call the web service to authenticate again.
I developed everything and it works well. In production I ran into worse timeouts and found out that my sql connection is the problem. The connection pool overloaded. I fixed this with a bad workaround to set the pool size to very large number.
Now here is my problem / question:
Does anyone know if this module will stay in memory in any way so I can store a token in memory - application pool scope? The idea is to store the tokens in memory while the application runs. But I can't find any information to help me to find out how the module is handled in IIS7 and if my idea is a solution for the problem.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您不会将模块本身保留在内存中，但常见的是使用加密的 cookie 或会话来维护信用。不过，听起来你有点把问题混为一谈了。您的模块听起来可以（并且应该）由自定义成员资格提供程序处理，然后由自定义身份验证模块处理。
假设（根据您的帖子）您通过网络（表面上是从 Web 表单）获取某人的用户名和密码，您应该使用 ASP.NET 中的表单身份验证提供程序，然后实现一个 customMembership 提供程序来执行实际操作信用检查。然后，Forms Atuh 提供程序可以处理维护您的应用程序和用户浏览器之间的身份验证令牌。
You wouldn't keep the module itself in memory, but what's common would be to use an encrypted cookie or session to maintain the creds. It sounds like you're conflating problems a bit, though. Your module sounds like it can (and should) be handled by a custom Membership Provider, nto a custom authentication module.
Assuming (based on your post) that you're taking a person's username and password over the web (ostensibly from a web form), you should use the Forms Authentication provider in ASP.NET, and then implement a customMembership provider for doing the actual creds checking. The Forms Atuh provider can then handle maintaining the auth token between your app and the user's browser.