2009 m. gruodžio 27 d., sekmadienis

Communication between WCF and JBoss server via REST

Part 2: Using ssl + basic auth

Providing plain credentials over a secure transport layer is considered as quite secure way to communicate.

Let's build a secure Rest client:

using (HttpClient client = new HttpClient()) // needs disposal
  client.DefaultHeaders.ContentType = "text/xml";
  client.TransportSettings.Credentials = new NetworkCredential("username", "password");
  ServicePointManager.Expect100Continue = false;

 ServicePointManager.ServerCertificateValidationCallback = (object sender, X509Certificate certificate, X509Chain chain, SslPolicyErrors sslPolicyErrors) => { return true; };

 Account newAccount = new Account()
     Id = 0,
     Name = “FirstUser”

  HttpResponseMessage resp = lient.Post("http://example/account", newAccount);

  resp.EnsureStatusIsSuccessful(); // fires exceptions
  Status status = resp.Content.ReadAsXmlSerializable<Status>();

The property ServicePointManager.Expect100Continue solves different Http1.1 interpretation problem between Java .NET.

This case is covered in the HTTP/1.1 (RFC 2616) specification in section 8.2.3:

"Because of the presence of older implementations, the protocol allows ambiguous situations in which a client may send "Expect: 100-continue" without receiving either a 417 (Expectation Failed) status
or a 100 (Continue) status. Therefore, when a client sends this header field to an origin server (possibly via a proxy) from which it has never seen a 100 (Continue) status, the client SHOULD NOT wait for an indefinite period before sending the request body."

This problem appeared only when I'd added security to my client. Probably it is related to increasing waiting time.

ServicePointManager.ServerCertificateValidationCallback is used only in testing mode. The purpose is to override certificate validation which would cause exception becouse we don't have one in a testing stage.

  • http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html