It’s not about what we have, it’s about what we share that counts – Part Five.

  • Article

Windows Live Messenger Connect: In parts one, two, three and four we looked at how the OAuth WRAP profile is implemented with Windows Live Messenger Connect. Part Four just got in to a tiny bit of code. This post goes deeper, finishes off the code to get a simple site to display some Windows Live Profile information. Importantly though, it continually references the protocol diagram at Figure 3 (part one) and aligns that with what the code is doing.

Callback URL

Remember from figure 3, step 11 (in part one) the callback handler has access to the same secret that is used at the management portal. Because we’re talking about a Microsoft web environment in this blog post, we’ll use an assembly that Microsoft provides as part of the SDK. It’s all packaged up for us. If you insist on some other technology, there are example callback handlers in Flash, Java, ASP.NET, PHP and Python available here.

We’ll use the supplied assembly from the SDK. First a reference needs to be made to it and then a couple of entries made in web.config.

image

Figure 8: Location of the OAuthWRAPCallback handler assembly – Microsoft.Live.AuthHandler.dll

In system.web add the following HTTP handler.

 <httpHandlers>
      <add verb="*" path="OAuthWrapCallback.ashx"
           type="Microsoft.Live.OAuthWrapHandler, Microsoft.Live.AuthHandler"/>
</httpHandlers>

This associates the type, Microsoft.Live.OAuthWrapHandler within the Microsoft.Live.AuthHandler assembly with the path “OAuthWrapCallback.ashx”.

Next, add the following to web.config replacing the client secret and client id with the data you obtained when you registered your application at manage.dev.live.com and as shown in figure 2 of part one.

 

 <appSettings>
        <add key="wl_wrap_client_secret" value="xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"/>
        <add key="wl_wrap_client_id" value="00000000xxxxxxxx"/>
<add key="wl_wrap_client_callback"         value="https://www.cantasa.com:8080/OAuthWrapCallback.ashx"/>
        <add key="wl_wrap_sessionId_provider_type" value="AuthIntegration" />
</appSettings>

Notice the value of the callback handler – OauthWrapCallback.ashx. And then reference the example in the httpHandler section above to see how this is now handled by the assembly from the SDK.

Also notice the value of this key is the entire URL. When you registered your application, you provided this URL. The callback handler passes this value (in this case https://www.cantasa.com:8080/OAuthWrapCallback.ashx ) to Windows Live. Windows Live will check that the supplied URL matches the stored URL. This means you will need to ensure your application is running against that real URL – so make sure you set the domain portion of the Start URL to the correct value in Visual Studio. You can’t run it at localhost.

image

Figure 9: The Start URL needs to have the domain portion set the same as the URL registered at manage.dev.live.com.

If the callback handler was running over SSL (and therefore the URL started “https”), the application would work at this stage. Most of us in the development environment are not running SSL – so you can see an additional line in appSettings called wl_wrap_sessionId_provider_type.

This references a class that provides a session ID as shown below:

 

 public class AuthIntegration : Microsoft.Live.ISessionIdProvider
{
    public string GetSessionId(System.Web.HttpContext context)
    {
        return context.Session.SessionID;
    }
}

This session id is needed in the page you created with the wl: controls in part four. I left a little bit unexplained with this line:

 

 callback-url="/OAuthWrapCallback.ashx?wl_session_id=<%= Session.SessionID %>"

You can now see where the session ID comes from. It’s used for the callback handler and all the java libraries to keep track of things.

If you now press F5 and run the application – you’ll get something like this: after you’ve authenticated through the Windows Live Consent UI:

image

Figure 10: Running the application to retrieve the Live data

Steps 8 through 17 of figure 1 (in part one) are now completed. You added the callback handler which meant your application could retrieve the verification code and then add to it the client secret and pass it back to Windows Live. Windows Live verified the code and the secret, saw it had issued that verification code and that your application also knew the previously generated client secret. With Windows Live now being very assured that your application is genuinely what it purports to be, it generated the refresh token the access token and the lifetime and passed that back. The callback handler then used channel.html to turn the token data in to cookies.

The <wl:userinfo/> tag caused the javascript downloader to bring in enough javascript libraries to parse the cookies and generate a request to the Windows Live API Service with the access token in the header. You may have noticed a delay between the successful authentication in the consent page and the rendering of the Windows Live information in the userinfo tag. The delay is caused by not only the request for the data, but the amount of javascript that has to be downloaded to achieve the task. It’s the same when the page loads for the first time – you may have noticed a delay before the “Connect” button is rendered. Loader.js has a lot of work to do…. You’ll now understand the reason the javascript libraries have been minimised, simply to improve load times.

I hope you found this series of posts interesting in that they told you not only what code to use but also what the code was doing at a protocol level. Now that you have an understanding of OAuth WRAP – you’re in a great position to start playing around with Windows Azure and the Access Control Service in AppFab!!!!

If you want to follow along exactly – I used the walkthrough samples as the basis for the description of the protocol. They take things a little further but unfortunately there is no description of how the code is driving the OAuth WRAP profile behind it all. These posts should have given you a real leg up to understanding that – I hope…

I’ve actually wrapped the whole five articles up in to a pdf doc you might find interesting as a reference.

imageclick the image above to read the entire set of 5 posts as one pdf document.

Planky