在 Asp.Net 中模拟用户
我的 DBA 要求所有数据库访问都通过受信任的域帐户完成。 如果您设置 web.config 就可以完成此操作。 这要求用户登录或位于 IE 域中以传递凭据。 我想通过使用代码来模拟用户。 我正在使用此知识库文章中找到的代码：
http://support.microsoft.com/kb/306158
它工作得很好，我传入凭据，模拟用户，然后调用数据库并返回数据。
问题是，如果我转到另一个页面，我就会丢失我的模拟凭据。 这意味着每次调用数据库时我都必须运行模拟代码。
如果 IIS 可以模拟所有页面的域用户，那么为什么我在使用代码时不能模拟用户呢？
这似乎与线程上下文切换有关。 我尝试在 Aspnet.config 文件中设置alwaysFlowImpersonatingPolicy，但它不起作用。
http://msdn.microsoft.com/en-us/library/ms229553。 aspx
有什么建议吗？ 甚至可以做我想做的事吗？
My DBA requires all database access to be done through trusted domain account. This can be done if you set the web.config . This requires the user to login or to be on the domain for IE pass the credentials through. I want to impersonate a user by using code. I am using the code found in this knowledgebase article:
http://support.microsoft.com/kb/306158
It works great, I pass in the credentials, impersonate the user, then make the call to the database and data is returned.
The problem is if I go to another page, I lose my impersonated credentials. This means every time I make a call to the database I have to run the impersonate code.
If IIS can impersonate a domain user for all pages, then why can I not impersonate a user while using code?
It seems to be something with thread context switching. I have tried setting the alwaysFlowImpersonatingPolicy in the Aspnet.config file and it did not work.
http://msdn.microsoft.com/en-us/library/ms229553.aspx
Any suggestion? Is it even possible to do what I want?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
模拟发生在线程级别。 模拟会导致线程的访问令牌（通常是从进程继承的）被替换为另一个。 最佳实践是在完成所需的操作后立即恢复模拟的效果，从而恢复令牌。 IIS 或 ASP.NET 的情况没有什么不同。 每个请求通常由不同的线程处理，因此您必须使每个线程模拟用户。
所以这是正确的。
IIS 的做法没有任何不同，因此它可能只是一种感知的错觉。 它无法模拟所有页面的用户，除非所有页面都由同一线程提供服务，并且在提供每个页面时从未恢复模拟的令牌。
并不真地。 除非您正在进行异步处理（您在问题中没有声明您这样做），否则模拟上下文的流程将不相关。 如果您在处理单个请求期间直接或间接导致线程切换，则只需担心模拟上下文的流动。 如果您希望辅助（工作）线程完成的工作继续在主线程的模拟上下文中进行，那么您需要确保辅助线程借用模拟令牌。 在 .NET Framework 1.1 中，您必须非常小心并手动编排模拟上下文的流程。 但是，在 .NET 2.0 中， ExecutionContext API被引入并做了很多繁重的工作。
Impersonation occurs at the level of the thread. Impersonation causes the access token of the thread, which is usually inherited from the process, to be replaced with another. The best practice is to revert the effect of impersonation and thus the token as soon as you are done with the operation(s) for which it was needed. The story is no different with IIS or ASP.NET. Each request is usually handled by a distinct thread so you will have to make each thread impersonate the user.
So that is correct.
IIS does not do it any differently and so it may only be a perceived illusion. It cannot impersonate a user for all pages unless all pages are being served by the same thread and where the impersonated token has never been reverted as each page is served.
Not really. Unless you are doing asynchronous processing (which you don't state you do in your question), the flow of the impersonation context won't be relevant. You only need to worry about flowing the impersonation context if you are causing a thread switch either directly or indirectly during the processing of a single request. If you want that the work done by a secondary (worker) thread continues to occur under the impersonation context of the primary one then you need to make sure the secondary thread borrows the impersonation token. In .NET Framework 1.1, you would have to take great care and manually orchestrate the flow of the impersonation context. With .NET 2.0, however, the ExecutionContext API was introduced and does a lot of the heavy-lifting.
您丢失模拟上下文的原因是因为每次新页面请求结束时模拟上下文都会超出范围。
根据文档
The reason you're losing the impersonation context is because each time a new page request ends the impersonation context will go out of scope.
As per the docs
<alwaysFlowImpersonationPolicy>is used to ensure the same impersonation context is maintained across async calls. For example when making an async call to a remote web service the callback impersonation context is the same one as the initiating thread. In the case of ASP.NET the impersonation context would only flow for the lifetime of the page request.