Why doesn't my WCF endpoint throw a Max Clock Skew exception?
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>
&l开发者_如何学运维t;/wsHttpBinding>
</bindings>
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.
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.
精彩评论