任务/线程内的 CredentialsCache.DefaultCredentials

发布于 2024-12-09 19:52:36 字数 246 浏览 0 评论 0原文

我希望你能帮助我。

我正在我的 C# 4.0 应用程序中执行一些需要身份验证的网络请求。我只是使用CredentialsCache.DefaultCredentials。只要我不通过 Task.Factory.StartNew(...) 在不同的线程/任务中运行该功能，这种方法就非常有效。然后我收到 401 错误。我假设凭据没有传递给子线程？

如何将凭据传递给任何子任务/线程？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

江城子 2024-12-16 19:52:36

我假设您正在使用模拟，问题是凭据没有流入任务。值得检查这一点，通过在启动代码和任务主体中转储 Windows.Identity.GetCurrent().Name 的值并确保它符合您的预期，从而避免白费力气。

因此，鉴于上述情况，有几种方法（正式地说）执行上下文（或只是安全上下文）不会跨线程流动。默认行为是上下文是流动的 - 所以一定有什么东西在影响它。

1) 某些内容已设置 ExecutionContext.SuppressFlow() - 您可以通过转储任务内 ExecutionContext.IsFlowSuppressed() 的值来检查这一点。

2）有一个配置元素（configuration->runtime->legacyImpersonationPolicy）默认为false。当false时，WindowsIdentity在异步点之间流动。当true时，它不是。这与 ExecutionContext 流设置无关。所以这里的 true 会给你带来问题。您可以通过转储 SecurityContext.IsWindowsIdentityFlowSuppressed() 的值来检查这一点是您的任务。这也可以使用 SecurityContext.SuppressFlowWindowsIdentity() 以编程方式针对每个线程进行设置。

最后，为了完整起见，如果您使用非托管代码，还有另一个设置也可以控制模拟凭据在非托管场景中的流动方式；描述的其他设置仅影响托管代码。

回复收藏 0 原文

断爱 2024-12-16 19:52:36

万一其他人遇到这个问题......我的有点不同。我的 WCF 服务作为 REST 服务和 SOAP 公开，安全上下文来自 System.Web.HttpContext.Current 或 System.ServiceModel.OperationContext.Current。我的 DAL 使用这些上下文之一通过检查 HttpContext.Current.User.Identity 或 OperationContext.Current.ClaimsPrincipal.Identity 来识别当前用户。

因此，对于我的情况，我必须将这两个上下文保存在并行 foreach 外部的变量中，然后将它们设置在并行内部以保存值。这似乎成功了。经过一些修改，相同的概念也适用于其他 TPL 情况。

var httpcontext = System.Web.HttpContext.Current;
var opcontext = System.ServiceModel.OperationContext.Current;
Parallel.ForEach(types, (p) =>
{
    System.Web.HttpContext.Current = httpcontext;
    System.ServiceModel.OperationContext.Current = opcontext;

    // DO YOUR PARALLEL PROCESSING HERE
});

In case someone else comes across this issue... mine was a little different. My WCF service is exposed as a REST service as well as a SOAP, with the security context coming from either System.Web.HttpContext.Current or System.ServiceModel.OperationContext.Current. My DAL uses one of those contexts to identify the current user by checking HttpContext.Current.User.Identity or OperationContext.Current.ClaimsPrincipal.Identity.

So for my case, I had to save those two contexts in variables outside of the parallel foreach and then set them inside the parallel to the saved values. That seemed to do the trick. The same concept could work for other TPL situations with some modifications.

var httpcontext = System.Web.HttpContext.Current;
var opcontext = System.ServiceModel.OperationContext.Current;
Parallel.ForEach(types, (p) =>
{
    System.Web.HttpContext.Current = httpcontext;
    System.ServiceModel.OperationContext.Current = opcontext;

    // DO YOUR PARALLEL PROCESSING HERE
});

回复收藏 0 原文

~没有更多了~