为什么我的 WCF 端点不抛出最大时钟偏差异常?

发布于 2024-09-13 05:05:11 字数 1231 浏览 5 评论 0原文

对于我的应用程序中的几乎所有(安全)WCF 服务端点,如果客户端的系统时钟设置在未来或过去太远,我会从 WCF 时钟偏差机制中得到异常(此处描述:http://www.danrigsby。 com/blog/index.php/2008/08/26/change-the-default-clock-skew-in-wcf/)。

然而,实现我的 Login() 方法的一个端点永远不会抛出此异常,即使它启用了传输安全性(当然不需要凭据)。

为什么“时钟偏差机制”对此端点不起作用?也许是因为 clientCredentialType 设置为“None”?

作为示例,这是我的配置的简化版本:

<services>
    <service name="Foo">
        <endpoint address=""
            binding="wsHttpBinding"
            bindingConfiguration="binding1"
            contract="IFoo" />
    </service>
</services>

<bindings>
    <wsHttpBinding> 
        <binding name="binding1" maxReceivedMessageSize="100000000">
            <readerQuotas maxDepth="1000000000" maxArrayLength="1000000000" maxStringContentLength="1000000000" />
            <security mode="Transport">
                <transport clientCredentialType ="None"/>
            </security>
            <reliableSession enabled="false" />
        </binding>
    </wsHttpBinding>    
</bindings>     

With almost all of the (secure) WCF service endpoints in my application, if the client's system clock is set too far in the future or past, I get an exception from WCFs Clock Skew mechanism (described here: http://www.danrigsby.com/blog/index.php/2008/08/26/changing-the-default-clock-skew-in-wcf/).

However the one endpoint where my Login() method is implemented never throws this exception even though it has transport security enabled (naturally no credentials are required for it).

Why isn't the "Clock Skew mechanism" working for this endpoint? Maybe it's because clientCredentialType is set to "None"?

As an example, here's a simplified version of my configuration:

<services>
    <service name="Foo">
        <endpoint address=""
            binding="wsHttpBinding"
            bindingConfiguration="binding1"
            contract="IFoo" />
    </service>
</services>

<bindings>
    <wsHttpBinding> 
        <binding name="binding1" maxReceivedMessageSize="100000000">
            <readerQuotas maxDepth="1000000000" maxArrayLength="1000000000" maxStringContentLength="1000000000" />
            <security mode="Transport">
                <transport clientCredentialType ="None"/>
            </security>
            <reliableSession enabled="false" />
        </binding>
    </wsHttpBinding>    
</bindings>     

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

扫码二维码加入Web技术交流群

发布评论

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

评论(2

尽揽少女心 2024-09-20 05:05:11

安全模式 - security mode="Transport" - 消息中不包含时间戳,这会导致 MaxClockSkew 验证忽略消息并且不会引发安全异常。
将安全模式更改为安全模式 =“TransportWithMessageCredential”,其中包含时间戳并允许 MaxClockSkew 验证来测试消息的时间增量。

The security mode - security mode="Transport" - does not include time stamp in the message which cause the MaxClockSkew validation to ignore the message and not throws a security exception.
Change the security mode to security mode="TransportWithMessageCredential" which include time stamps and allow the MaxClockSkew validation to test the message for time delta.

感性不性感 2024-09-20 05:05:11

其他人也有类似的问题:

在访问WCF服务时触发MaxClockSkew

所以我这样做不认为是你的配置问题。

看来,如果它不使用机器时间,它不会检查机器之间是否存在时间差异。

您可以围绕它进行编程,将客户端计算机时间作为登录方法中的参数发送,如果不同,则抛出异常。

Other people have a similar problem:

Triggering MaxClockSkew when accessing WCF service

So I do not think that it is a problem with your configuration.

It appears to be, that if it does not use machine time, it does not check if there is a difference in time between the machines.

You could program your way around it, send the client machine time as a parameter in your login method, if it is different, throw an exception.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文