| Comments

A little bit of hidden gem in the Silverlight 4 release is the ability to modify the Authorization header in network calls.  For most, the sheer ability to leverage network credentials in the networking stack will be enough.  But there are times when you may be working with an API that requires something other than basic authentication, but uses the Authorization HTTP header.

The Details

Basically you just set the header value.  How’s that for details :-). 

Seriously though, here’s a snippet of code:

   1: WebClient c = new WebClient();
   2: c.Headers[HttpRequestHeader.Authorization] = "Auth header from same domain-browser stack";
   3: c.DownloadStringCompleted += ((s, args) =>
   4:     {
   5:         if (args.Error != null)
   6:         {
   7:             response.Text = args.Error.Message;
   8:         }
   9:         response.Text = args.Result;
  10:     });
  11: c.DownloadStringAsync(new Uri(http://localhost:4469/handler.ashx));

As you can see in the code is rather simple.  Prior to Silverlight 4 you’d receive an exception that setting the header isn’t possible…but now it is.  If you are using HttpWebRequest instead it would be just as simple:

   1: HttpWebRequest req = (HttpWebRequest)WebRequest.CreateHttp("http://localhost:4469/handler.ashx");
   2: req.Headers[HttpRequestHeader.Authorization] = "Auth header from same domain using HWR";
   3: req.BeginGetResponse((cb) =>
   4:     {
   5:         HttpWebRequest rq = cb.AsyncState as HttpWebRequest;
   6:         HttpWebResponse resp = rq.EndGetResponse(cb) as HttpWebResponse;
   7:  
   8:         StreamReader rdr = new StreamReader(resp.GetResponseStream());
   9:         string foo = rdr.ReadToEnd();
  10:         Dispatcher.BeginInvoke(() =>
  11:             {
  12:                 response.Text = foo;
  13:             });
  14:         rdr.Close();
  15:  
  16:     }, req);

That’s it.

The Support Matrix

As such this feature does have some restrictions for security reasons.  Basically the difference has to do with cross-domain calls.  Here’s the feature support matrix in the simplest terms:

Network Stack UsedDomain TypeAuthorization Header Allowed
Browser (default)same domainYes
ClientHttpsame domainYes
Browser (default)cross-domainYes with policy
ClientHttpcross-domainYes with policy

As you can see a cross-domain call of this (i.e., setting an Authorization header on a 3rd party site) would require that a valid clientaccesspolicy.xml be in place.  Here’s an example of a pretty liberal one:

   1: <?xml version="1.0" encoding="utf-8" ?>
   2: <access-policy>
   3:     <cross-domain-access>
   4:         <policy>
   5:             <allow-from http-request-headers="Content-Type,Authorization">
   6:                 <domain uri="*"/>
   7:             </allow-from>
   8:             <grant-to>
   9:                 <resource include-subpaths="true" path="/"/>
  10:             </grant-to>
  11:         </policy>
  12:     </cross-domain-access>
  13: </access-policy>

I should note that when I mean ‘pretty liberal’ this means that the above makes all your resources available to all Silverlight clients.  But pay attention to the http-request-headers section.  Notice the addition of the Authorization header (Content-Type is default always).  By adding this you would be able to have a cross-domain Authorization header writing ability.  Without it you’d see a security exception.  And remember, the policy files exist on the destination endpoint and not in your app.  To demonstrate this, here’s my quick sample application output:

Auth header sample app output

You can download the code for this sample tester application here: Authheaders.zip

Summary

Hopefully this is good news to some developers.  Now with Silverlight 4 we have network credentials support and the ability to use the Authorization header when needed for other purposes.  It’s a little hidden gem that frankly could have been better called out in the docs a bit.

Hope this helps!

| Comments

We’ve update the .NET RIA Services build for May 2009.  The updated May preview can be downloaded here: .NET RIA Services May 2009.  You may have to uninstall your previous version before installing this one. 

What is .NET RIA Services?
Microsoft .NET RIA Services simplifies the traditional n-tier application pattern by bringing together the ASP.NET and Silverlight platforms. The RIA Services provides a pattern to write application logic that runs on the mid-tier and controls access to data for queries, changes and custom operations. It also provides end-to-end support for common tasks such as data validation, authentication and roles by integrating with Silverlight components on the client and ASP.NET on the mid-tier.

This update incorporates a bunch of fixes that have been reported in the RIA Services forum.  This is a good place to report issues and communicate with the dev team.  Most fixes came from the forum.  In addition, DomainService base classes now infer some data access metadata based on the model (length, required for example).  There are a few other samples that were added to this as well to note:

Also upon installing you’ll see a new project type called the Business Application Template.  Right now it looks and feels exactly like the navigation template with the Silverlight tools, but has a few defaults added, namely authentication.  You’ll see in the ASP.NET project there with a Services folder and three new files: AuthenticationService, UserInformation, UserRegistrationService.  These are all services to expose authentication and membership integration.  Running the template by default will give you a new “login” link in the upper right and clicking on that implements a new ChildWindow for login:

Biz App Login Template

Notice the "Register now” link which then uses another ChildWindow control for registration:

Biz App Register Template

Registering a new user uses the UserRegistrationService to add a new user to the system.  If you look at the UserRegistrationService you’ll see that it uses the ASP.NET Membership APIs:

   1: namespace BusinessApplication2.Web
   2: {
   3:     [EnableClientAccess]
   4:     public class UserRegistrationService : DomainService
   5:     {
   6:         // NOTE: This is a sample code to get your application started. In the production code you would 
   7:         // want to provide a mitigation against a denial of service attack by providing CAPTCHA 
   8:         // control functionality or verifying user's email address.
   9:  
  10:         public void AddUser(UserInformation user)
  11:         {
  12:             MembershipCreateStatus createStatus;
  13:  
  14:             // NOTE: ASP.NET by default uses SQL Server Express to create the user database. 
  15:             // CreateUser will fail if you do not have SQL Server Express installed.
  16:  
  17:             Membership.CreateUser(user.UserName, user.Password, user.Email, user.Question, user.Answer, true, null, out createStatus);
  18:             if (createStatus != MembershipCreateStatus.Success)
  19:             {
  20:                 throw new DomainServiceException(ErrorCodeToString(createStatus));
  21:             }
  22:         }
  23:         
  24:         // other methods exist here
  25:         // ...
  26:     }
  27: }

Because the membership APIs are provider-based, you can leverage whatever you want for your membership model and still use those APIs.  The example uses the default mechanism in ASP.NET.

Download the updated RIA Services bits today and take a look at the new template for integrating with the various ASP.NET providers.  Thanks for the continued feedback and keep it coming!

| Comments

some news on the windows live platform front...now you can link your passport live id accounts!  i like a lot of the windows live services, but one that i've struggled with is live id.  not the concept, but rather the implementation.  it is getting incrementally better day by day and this one change in particular made me happy.

when passport first came out, most got one.  when messenger came out, you used your passport.  then you could create a passport/live id with your own email account (didn't have to be hotmail.com), then there were some changes and you might have had to migrate yours...etc.  you can see where i'm going here -- i have roughly 4 live id accounts.

then you have your corporation, like mine :-) -- sometimes they require registrations from a live id ending in @mycorpdomain.com -- that frustrates me, but oh well.  i basically have two primary live id accounts i use and when i login/out of sites because i may have created sites under one account, etc. -- i would have to lose major context of what i was doing...not anymore!

here's what you do to link your various live id accounts...

1) go to http://account.live.com and login with your preferred live id

after you login you'll see the summary page and on it you should see the "Linked Windows Live IDs" section:

2) click on the 'Manage Linked IDs' and you should see:

3) click on the 'Link an existing Windows Live ID' and you'll be asked to confirm your logged in live id password, and then you'll be able to add another Windows Live ID account:

4) once completed you'll see that your accounts are now linked:

great, so now what? well when you go to a live id-enabled site you'll be able to switch identities immediately on that site without having to logout/login to a different windows live id...you'll be instantly changed on the same site...that is awesome.

so go link your most used windows live ids!  thanks windows live team!