WCF 获取“主签名必须加密。” 来自带有 ProtectionLevel.None 的故障合约
我有一个现有的 asp.net 应用程序，它与负载平衡的 wcf 服务进行通信（iis 托管，在配置为 servicePrincipalName 的帐户下运行的应用程序池中，等等）。 wcf 服务返回一些自定义错误，所有错误均使用FaultContract(typeof(x), ProtectionLevel = ProtectionLevel.None) 定义——这些服务不向公众公开。 客户端使用“服务引用”生成的类来访问服务。
这工作得很好，但现在，使用最新的代码库，我们得到“主签名必须加密”。 当服务返回这些错误之一时，客户端上会出现异常。 服务代码和配置保持不变（至少是产生故障的遗留部分）。 客户端服务引用生成的代码似乎变化最大（它经常被删除并重新创建）。
一年多来安全配置没有变化。 所有更新都是最新的。 我们已经在三个环境中对此进行了测试，一旦我们部署新的代码库，错误就开始生成异常。 似乎它必须在生成的类中，但它们是由 Visual Studio 生成的，因此非常令人困惑。
这听起来很熟悉吗？ 有什么建议么？
更新：删除 ProtectionLevel 属性并允许其默认使问题“消失”，但我很好奇为什么指定 None 会导致它失败。 也许它与运营合同或服务合同的默认级别相冲突，但这些值在过去一年中没有改变，因此这并不能解释为什么现在有效的方法不起作用。
更新：就其价值而言，代码生成中的此更改发生在 2.0.50727.3053 和 2.0.50727.3082 之间（根据生成的代码中的运行时版本注释）。
I have an existing asp.net application that talks to load balanced wcf services (iis hosted, in app pool running under account configured as servicePrincipalName, etc.). The wcf services return a few custom faults, all defined with FaultContract(typeof(x), ProtectionLevel = ProtectionLevel.None) -- these services are not exposed to the public. The client uses the 'service reference' generated classes to access the services.
This has worked fine but now, with the latest code base, we are getting "The primary signature must be encrypted." exceptions on the client when the service returns one of these faults. The service code and configuration is unchanged (at least the legacy parts that generate the faults). The client side service reference generated code appears the most changed (it often gets removed and recreated).
The security configuration is unchanged for over a year. All the updates are pretty current. We've tested this in three environments and as soon as we deploy the new code base, the faults start generating exceptions. Seems like it has to be in the generated classes but they are generated by Visual Studio so it is very perplexing.
Does this sound familiar to anyone? Any suggestions?
Update: Removing the ProtectionLevel attribute and allowing it to default makes the problem 'go away', but I am curious why specifying None causes it to fail. Perhaps it conflicts with the default level of the operation contract or service contract, but those values have not changed in the past year so that doesn't explain why what had worked now doesn't.
Update: For what it is worth, this change in code gen happened between 2.0.50727.3053 and 2.0.50727.3082 (according to the runtime-version comment in the generated code).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我自己没有遇到过这个问题，但我的问题是：你到底为什么在你的故障合约中指定“ProtectionLevel=None”？ 有什么特别的原因吗？
如果没有，我强烈建议根本不指定 - 默认值为 ProtectionLevel=EncryptAndSign，这通常是您最好的选择。 尝试一下，除非你有非常强烈和明确的理由反对它。
马克
I haven't experienced this problem myself, but my questionn is: why on earth do you specify a "ProtectionLevel=None" in your fault contract? Any particular reason for that?
If not, I'd strongly recommend not specifying that at all - the default is ProtectionLevel=EncryptAndSign and that's usually your best bet all around. Try it, unless you have a very strong and explicit reason against it.
Marc