Silverlight 3 – Did we get support for Credentials?

A few months ago, I investigated Silverlight 3 Beta on support for Credentials.

There are two classes that give a little bit of notion that they are supporting Credentials. Both WebClient and WebRequest have a property Credentials of type ICredentials. Let’s try them one by one.

WebRequest credentials support?

First we need to have some code to request the content behind an url and assign a set of credentials to the request.

WebRequest request = HttpWebRequest.Create("http://mark.mymonster.nl");
request.Credentials = new NetworkCredential("username", "password");

Very straightforward code which you can write for the full CLR as well. This code doesn’t even contain the execution of the request.

NotImplementedException when using Credentials on WebRequest

Yes it fails. If you try to set the de Credentials you will get a NotImplementedException. Sad, so we have not support for credentials in the WebRequest.

WebRequest credentials support outcome: Negative

WebClient credentials support?

Next class with a Credentials property, WebClient. First let’s write some code.

var client = new WebClient
                 {
                     Credentials =
                         new NetworkCredential("username", "password")
                 };
client.DownloadStringCompleted += client_DownloadStringCompleted;
client.DownloadStringAsync(new Uri("http://mark.mymonster.nl"));

Of course if anything goes wrong we can see it in the DownloadStringCompleted. From QuickWatch, we can see what happened.

NotImplementedException when using Credentials on WebClient

Hmm, I could have guessed that WebClient internally makes use of WebRequest. So also WebClient doesn’t support credentials.

WebClient credentials support outcome: Negative

Hmm, last option we have: Adding the Authorization header manually

In the past I also tried to add the Authorization header manually. I won’t go into the details but, the implementation of the Credentials property would mean that some data would be put into the Authorization header.

ArgumentException when trying to apply an Authorization Header

Sad, this still doesn’t work. The ‘Authorization’ header cannot be modified directly.

Manually adding Authorization header outcome: Negative

Conclusion

Sadly both WebClient and WebRequest don’t support Credentials yet. I would have thought it did support, basically because they supplied a property called Credentials that wasn’t in the Silverlight 2 release. I’m just wondering if they just didn’t get the implementation in place on time for the RTW of Silverlight 3.

Trying to do it manually isn’t supported as well. I’m just wondering why do we have a property Credentials on those objects? Would be nice to get some response from the Silverlight team on this one.

Ps. This article is cross posted on: Mark Monster’s blog and Silverlight Help.

  • Gravatar Bart Czernicki July 11th, 2009 at 20:36
    Mark,

    Did you try the new Networking client with Silverlight? I think it supports adding a the Authorization header (I think I heard Tim Heuer mention it).
  • Gravatar Mark Monster July 11th, 2009 at 20:47
    Thanks for reply

    I just tried.

    Using <b>WebRequestCreator.ClientHttp.Create</b> instead of <b>WebRequest.Create</b> to create a HttpWebRequest doesn't allow me setting the Authorization header as well.

    -
    Mark Monster
  • Gravatar Nicholas Bedworth July 12th, 2009 at 18:58
    Mark, Bart...

    So what to do? We are really interested in ClientHTTP support. Let's say we want to access a Mesh folder somewhere; if the user has the Mesh folder on the desktop (has become a member of it) is authentication required?

    Tim is definitely aware of this.

    Nick
  • Gravatar John July 12th, 2009 at 19:07
    I agree. My company has some new RESTful services exposing our content management product. I need to be able to PUT and DELETE for content, but with a login. The clienthttp seems to work fine with anonymous access, but who would allow a PUT or DELETE anonymously anyway. This is the one feature I was REALLY hoping would be fixed in SL3.
  • Gravatar timheuer July 12th, 2009 at 20:20
    The modifications of Authorization header information is not available in SL3 :-( -- it's something still being considered for future versions. The ClientHttp stack was introduced based on customer feedback and it still being improved. Some of the key benefits are access to more verbs as well as response status codes.
  • Gravatar Caleb Jenkins July 12th, 2009 at 23:29
    Yeah... that's pretty lousy. Let's hope we get true credential support soon! Thanks for running that down Mark. Great work.
  • Gravatar John July 12th, 2009 at 23:55
    Luckily, for our RESTful svcs, we offer "X-HTTP-METHOD-OVERRIDE" for PUTs and DELETEs from POST. But I would have loved to have used the new client stack. Guess I'll revisit it when SL4 beta comes out next year ...
  • Gravatar Eric Smith July 14th, 2009 at 19:21
    Our services also accept X-Authorization, which works great if you have control over that end. Not so helpful for 3rd party services, though.
  • Gravatar Andrew Staffer July 21st, 2009 at 01:51
    Thanks for clarifying this one Mark. Great job.
    I'd really like to urge the Silverlight team to make authentication a priority. We desperately need it in our applications.
  • Gravatar Jon July 27th, 2009 at 23:06
    I agree that that is pretty lame that the Credentials property is missing. I found the same to be true for WCF clients in Silverlight 2. I'm assuming that WCF clients are still using the browser's HTTP stack in 3. A work around would be to create a WCF service on the same server that your web app resides, then, make the REST requests on the server side (where you have complete access to the .NET Framework proper) and send back the results to Silverlight via WCF. Not exactly the most elegant solution, but, it could be used until Silverlight support credentials.
  • Gravatar Jon July 27th, 2009 at 23:09
    It's weird that you can't even set the Authorization header at the lowest level using the Dictionary. One would think that you could have at least done that. The must have put a check in there to prevent it. Maybe they're worried that it might be considered a bad programming practice and might cause some kind of bad security problem. i.e. caching client credentials in Silverlight. This is one of the things that IMHO makes developing RIA apps a much bigger hassle that server side apps. The security considerations.
  • Gravatar DotNetBurner - Silverlight September 13th, 2009 at 00:02
    <strong>Silverlight 3 – Did we get support for Credentials?...</strong>

    DotNetBurner - burning hot .net content...
  • Gravatar pallavi kr February 2nd, 2011 at 09:10
    Hi,

    ok.I do understand the problem that it neither supports WebClient or HttpWebRequest for Credentials, can you please tell me a better way to go with. any alternative to achieve.
    i require this very badly.
  • Gravatar Mark Monster February 2nd, 2011 at 11:55
    This is the case for Silverlight 3, but Silverlight 4 can help out.
Gravatar