The League Of Paul

Code52 - I'm going to be busy this year

paul@theleagueofpaul.com (Paul Jenkins) — Mon, 16 Jan 2012 00:00:00 +1100

Yup, 52 open source projects, one a week. It's going to be a hectic year. Join in, if you dare.

So far we've made MarkPad (week 1), a WPF/Metro MarkDown editor (which I've used to write this post!)

and Jibbr (week 2), a bot platform for Jabbr. I contributed the IronJS layer (although not 100% complete) which compiles CoffeeScript compiler, then CoffeeScript -> Javascript, and allows Hubot scripts. Unfortunately, I couldn't nut out the 'http' object properly, because of the weird syntax, so not all scripts work.

Next week could be intense.

MahApps.Metro 0.4 Released!

paul@theleagueofpaul.com (Paul Jenkins) — Fri, 06 Jan 2012 00:00:00 +1100

39 commits from three authors later, MahApps 0.4 is now out! There is a few breaking changes, but nothing significant has been removed so it shouldn't be too much to migrate.

Grab the latest source from GitHub, the latest release from NuGet or the latest demo via ClickOnce

What is fixed or changed?

Squared corners on ComboBox/ComboBoxItem and TextBox
ComboBoxItems now adjust width correctly
Fixed accent colour on ToggleSwitch
Many styles are separated out into their own files. This does mean if you want to include everything, you need to include more files, but it's a cleaner, more discoverable approach.
Accessor keys now work on TabItems
TabItems now work with datatemplates or plain strings (only worked with strings previously)
Better design time support for several controls
Fixed a few animations that crashed Visual Studio's designer
A few extra icons from Templarian's Project: Windows Phone Icons added
The assemblies are now strong named and signed
ToUpperConverter and ToLowerConverter are now markup extensions rather than converters

Usage

To use MahApps.Metro, add it via NuGet (Install-Package MahApps.Metro), then to any of your windows add the following to resources

   <Window.Resources>
        <ResourceDictionary>
            <ResourceDictionary.MergedDictionaries>
                <ResourceDictionary Source="pack://application:,,,/MahApps.Metro;component/Styles/Colours.xaml" />
                <ResourceDictionary Source="pack://application:,,,/MahApps.Metro;component/Styles/Fonts.xaml" />
                <ResourceDictionary Source="pack://application:,,,/MahApps.Metro;component/Styles/Controls.xaml" />
                <ResourceDictionary Source="pack://application:,,,/MahApps.Metro;component/Styles/Controls.AnimatedSingleRowTabControl.xaml" />
                <ResourceDictionary Source="pack://application:,,,/MahApps.Metro;component/Icons/MergedResources.xaml" />
                <ResourceDictionary Source="pack://application:,,,/MahApps.Metro;component/Styles/Accents/Blue.xaml" />
                <ResourceDictionary Source="pack://application:,,,/MahApps.Metro;component/Styles/Accents/BaseLight.xaml" />
            </ResourceDictionary.MergedDictionaries>
        </ResourceDictionary>
      </Window.Resources>

Due to existing WPF bugs, we can't add this to App resources.

What is new?

WindowCommands control.

It might look pretty boring but the WindowCommands is a combination of the traditional minimise, maximise/restore and close button. You don't have to use this, but it is there if you want those controls and is part of the new MetroWindow (more on that later).

WindowCommands is made up of three text buttons using the Marlett font. I discovered the wonders of Marlett via Bevan's Niche Software blog. By using text instead of images or instead of XAML, its simplier, smaller in filesize and scales so much better.

MetroWindow

This comes to MahApps.Metro via Cameron MacFarland.

While you still need to add the stack of ResourceDictionaries to the Window, MetroWindow simplifies the initial setup of MahApps.Metro.

<Controls:MetroWindow... instead of <Window... automatically adds the dropshadow behaviour, sets up Window movement (which is 'lost' when you remove default window chrome), the previously mentioned WindowCommands, and adds in the animated Metro Content Control.

You don't have to use this control, but I highly recommend you do just because it saves adding all that stuff by hand.

Buttons for everybody!

There are so many buttons!

Standard Button
This just replaces the standard button when you drop in the library, nothing fancy to activate it
MetroCircleButton
"Standard" circle button, designed for icons.
Add the following to a button to apply this style: Style="{DynamicResource MetroCircleButtonStyle}"

AppBarButton
Inspired by Windows Phone 7's app bar buttons which are a circle button with text underneath.

Use the AppBarButton control to use this type of button.

  <Controls:AppBarButton
                              VerticalAlignment="Top"
                              MetroImageSource="{StaticResource appbar_barcode}"
                              Foreground="{DynamicResource BlackBrush}"
                              Content="scan" />

Square button
Another WP7 styled button, this time just for text. Like all the buttons here, has normal, clicked, and hover states.

Add the following to a button to apply this style: Style="{DynamicResource SquareButtonStyle}"
FlatButton
Oh look! Another WP7 styled button! This sort of button can be found when you're making a call - all of the controls (hang up, keypad, etc) are 'flat buttons'.

Flat button lives in <ResourceDictionary Source="pack://application:,,,/MahApps.Metro;component/Styles/FlatButton.xaml" />, so you'll need to import that as well to use it.

WiX Auto-generation without using XLST

paul@theleagueofpaul.com (Paul Jenkins) — Sat, 31 Dec 2011 00:00:00 +1100

A quick recap: WiX (Windows Installer XML) is as the name implies XML based system of building installers. You gather your bunch of XML files that describe how you want the installer to look, function, etc, and when compiled with WiX, out pops an MSI. WiX is pretty much the defacto installer generation library - ClickOnce is balls, VS Installer is deprecated, and many other options either cost a fortune or simply just aren't as robust as WiX. While WiX is super powerful, it does have a bit of a learning curve which has given it a bit of a stigma.

I'm not too full of myself to say there are certain techs I suck at and don't want to learn. XLS/T is one of them. WiX (Windows Installer XML) is as the name implies XML based, and unfortunately that also means using XLST to transform any of the auto generated content from Heat (the "Harvest" tool which takes a directory and spits out a WiX fragment) into something a bit more usable. That's not to say Heat's output is useless, just for my particular configuration it wasn't "right".

There were a few approaches I could have gone for

Learn XLST - that sounded painful
Use C# to transform the XML generated by Heat.exe - more reasonable but still seemed pointless
Use C# to just generate the XML from a directory, skipping Heat.

While I'm my approach would incur the wrath of Rob Mensching, by using C# - a language I'm familiar with, a language I can maintain, I get a more robust install process.

As mentioned, WiX is all XML. .NET has a few ways to work with XML, but the absolute best? Linq-to-XML (XLinq).

static void Main(string[] args)
{
    var input = args[0];
    var output = args[1];

    XNamespace ns = "http://schemas.microsoft.com/wix/2006/wi";
    var document = new XDocument();
    var files = Directory.GetFiles(input).Select(x => new FileInfo(x));
    var diretories = Directory.GetDirectories(input).Select(x => new DirectoryInfo(x));
    var i = 1;
    document.Add(
        new XElement(ns + "Wix",
            new XElement(ns + "Fragment",
                new XElement(ns + "DirectoryRef",
                new XAttribute("Id", "INSTALLLOCATION"),
                    new XElement(ns + "Component",
                    new XAttribute("Id", "MahChatsFiles"),
                    new XAttribute("Guid", "4ac9e15b-89c1-4fde-84c9-286ef9d24af8"),
                    new XElement(ns + "RegistryKey",
                        new XAttribute("Root", "HKCU"),
                        new XAttribute("Key", @"Software\MahApps\MahChats"),
                        new XAttribute("Action", "createAndRemoveOnUninstall"),
                            new XElement(ns + "RegistryValue",
                                new XAttribute("Name", "Version"),
                                new XAttribute("Value", "[ProductVersion]"),
                                new XAttribute("Type", "string"),
                                new XAttribute("KeyPath", "yes"))),
                    new XElement(ns + "CreateFolder"),
                        new XElement(ns + "RemoveFolder",
                            new XAttribute("Id", "RemoveAppRootDirectory"),
                            new XAttribute("On", "uninstall")),
                            files.Select(x => new XElement(ns + "File",
                                new XAttribute("Id", x.Name.Replace('-', '_')),
                                new XAttribute("Source", x.FullName)))
                            ),
                            diretories.Select(x => new XElement(ns + "Directory",
                                new XAttribute("Id", x.Name.ToUpper()),
                                new XAttribute("Name", x.Name),
                                new XElement(ns + "Component",
                                    new XAttribute("Id", "ProductComponent" + i),
                                    new XAttribute("Guid", Guid.NewGuid()),
                                    new XElement(ns + "RegistryKey",
                                    new XAttribute("Root", "HKCU"),
                                    new XAttribute("Key", @"Software\MahApps\MahChats"),
                                    new XAttribute("Action", "createAndRemoveOnUninstall"),
                                        new XElement(ns + "RegistryValue",
                                            new XAttribute("Name", "Version"),
                                            new XAttribute("Value", "[ProductVersion]"),
                                            new XAttribute("Type", "string"),
                                            new XAttribute("KeyPath", "yes"))),
                                     new XElement(ns + "RemoveFolder",
                                        new XAttribute("Id", "ProductComponent" + i++),
                                        new XAttribute("On", "uninstall")),
                                    x.GetFiles().Select(y => new XElement(ns + "File",
                                        new XAttribute("Id", y.Name),
                                        new XAttribute("Source", y.FullName)))))
                                    )))));

    document.Save(output);
}

I'm sure many of you might balk at this gigantic statement, but (to me) it's more readable than XLST. It is a very specific query - for MahChats I'm toying with installing in a per-user, non-UAC required environment, like ClickOnce. That means it gets installed into C:\Users\User\AppData\Local\MahChats, and because it doesn't require elevation/is installed to that specific directory, I need to add in some registry keys and extra information.

The ultimate goal of this was to have the setup being generated by TeamCity as part of the CI build process. Now my build process looks like

Build project using Visual Studio Solution file
Use my "BurnTransformer" (specifically, BurnTransformer.exe %teamcity.build.checkoutDir%/src/MahChats/Bin/Release/ %teamcity.build.checkoutDir%\src\MahChats.Setup\fragment.wxs)
Build WiX project using a different Visual Studio Solution file
copy artifacts from src\MahChats.Setup\bin\**\*.msi

Why not ClickOnce which is "easier" and I've covered before? It's evil. Next month I hope to put out a "short horror story" on how ClickOnce is evil, and how to get similar installer experience (the good bits, that is) with WiX and other alternatives.

This means that yes, MahChats Alpha is getting closer. I still need a good/easy way to do updates, and I'm still in the process of setting up a custom NuGet server for (optional) plugins. On the installer front, I really want to take a look at WiX 3.6 which is currently in beta, as it has a way to do custom bootstrapper GUI's in WPF!

Shotty Rackspace upload plugin

paul@theleagueofpaul.com (Paul Jenkins) — Tue, 20 Dec 2011 00:00:00 +1100

Scott Hanselman's 2011 Dev Tools list included a new (to me) screenshot utility, Shotty. What's nice about these newer screenshot utilities is the ability to respect alpha transparency and drop shadows created by Aero - it's much nicer than having to line various windows up with a white background before taking a screenshot.

For all my blog posts I use Rackspace to store images, which unfortunately Shotty doesn't handle natively. Shotty is however a .NET 2.0 app, with a plugin API.

The code is up on GitHub, or you can download the compiled plugin - just unzip it into your Shotty directory.

At this stage, there is only root container level upload access. Later on, I'll add the ability to put it into subcontainers.

Using the new NugetGallery for your own purposes

paul@theleagueofpaul.com (Paul Jenkins) — Thu, 08 Dec 2011 00:00:00 +1100

Disclaimer: I only had 3-4 hours sleep last night, so I'm zonked but still coding. Please forgive me for the code sins I've probably commited and haven't realised.

For MahChats I'm wanting to seperate out the individual plugins from the main distribution - not everybody uses Skype or Messenger, so why have "bloat"? Matt Hamiliton demonstrated how easy it can be to have Nuget powered extensions in your app, taking care of browsing, distribution and updates.

I'm not one to underengineer things like Matt so a simple semi-static list that required manually uploading the files via FTP just wasn't going to cut it for me. However, I don't like paying too much for my hosting particularly for FOSS projects, so a combination of Rackspace and AppHarbor is perfect. After all, the new Nuget server is hosted on Azure, and AppHarbor is "Azure done right".

After checking out the Nuget Gallery source, it was pleasantly clear and easy to see what I'd have to replace if I wanted to change "cloud provider" for package storage.

Note: To compile the Nuget Gallery, you'll need to install the Azure SDK from Web Platform Installer or just delete all references to Azure.

Modify App_Start\PackageStoreType.cs. I just added in a fourth value, Rackspace.

 public enum PackageStoreType
 {
     NotSpecified = 0,
     FileSystem,
     AzureStorageBlob,
 }

became

 public enum PackageStoreType
 {
     NotSpecified = 0,
     FileSystem,
     AzureStorageBlob,
     Rackspace
 }

You'll then need to change your configure change config file to use new value in the enum. While we're at it, you may as well store the values of your container name, Rackspace username, and Rackspace token in the config. You can find your API token at in the Rackspace Management Console, once you've logged in. Open up web.config, look for the AppSettings section and add
```
 <add key="PackageStoreType" value="3" />
 <add key="ContainerName" value="<NameOfTheContainerToUse>"/>
 <add key="RackspaceUser" value="<RackspaceName>"/>
 <add key="RackspaceToken" value="<RackspaceToken>"/>
```

Implement just one interface - IFileStorageService. IFileStorageService is what ultimately tells Nuget where to put files and where to retrieve them from. This class makes use of the CloudFiles API Wrapper nuget package

 public class RackspaceStorage : IFileStorageService
 {
     private readonly UserCredentials _userCredentials = new UserCredentials(GetValue("RackspaceUser"), GetValue("RackspaceToken"));
     private Connection _connection;

     public Connection Connection
     {
         get { return _connection ?? (_connection = new Connection(_userCredentials)); }
     }

     public ActionResult CreateDownloadFileActionResult(string folderName, string fileName)
     {
         var container = Connection.GetContainerInformation(GetValue("ContainerName"));
         return new RedirectResult(Path.Combine(container.CdnUri, fileName), false);
     }

     public void DeleteFile(string folderName, string fileName)
     {
         Connection.DeleteStorageItem(folderName, fileName);
     }

     public Stream GetFile(string folderName, string fileName)
     {
         try
         {
             var file = Connection.GetStorageItem(folderName, fileName);
             file.ObjectStream.Position = 0;
             return file.ObjectStream;
         }
         catch (StorageItemNotFoundException)
         {
             return null;
         }
     }

     public void SaveFile(string folderName, string fileName, Stream packageFile)
     {
         Connection.PutStorageItem(GetValue("ContainerName"), packageFile, fileName);
     }

     private static string GetValue(string key)
     {
         return ConfigurationManager.AppSettings[key];
     }
 }

There is a switch statement (starts with switch (configuration.PackageStoreType)) in ContainerBindings.cs. which determines which storage mechanism is used based on the config. We just need to add a switch for our new package store.
```
 case PackageStoreType.Rackspace:
     Bind<IFileStorageService>()
         .To<RackspaceStorage>()
         .InSingletonScope();
```
Unless you've got a SSL cert/HTTPS server setup for your NuGet install, you'll need to disable HTTPS by going into AuthenticationController and removing [RequireRemoteHttps] from the LogOn() and public virtual ActionResult LogOn(SignInRequest request, string returnUrl) methods, otherwise you'll be caught in a redirect loop.
Finally, some of the settings cannot be set from the config file but must be entered in the database. You can do this directly using something like SQL Management Studio, or if you're debugging locally you can access http://localhost:55880/dbadmin/GallerySettings/List and add the values there.

After that, it's realy up to you to customise the gallery for how you want it to look.

As you can see, I still have a fair bit of work cut out for me in restyling the NuGet gallery, but I'm happy with the results of the Rackspace provider so far - I can upload/download via the NuGet tools just fine by just pointing it to /v1.

Once I've made a few extra customisations, I'll put a fork up on GitHub (and a follow up post) of the "complete" customisation - new theme, new storage provider, etc.

Pretzels

paul@theleagueofpaul.com (Paul Jenkins) — Sat, 03 Dec 2011 00:00:00 +1100

This recipe is originally from King Arthur Flour with some tweaks for Australian (instead of US) terminology and measurements. It's a good recipe, but not without a few confusing bits.

This recipe makes 8 pretzels, and takes just over an hour from start to finish (10 minutes work, 45 minutes resting/rising, ~10 mins baking)

Ingredients

Dough

2 ½ cups Plain Flour
½ teaspoon salt
1 teaspoon sugar
2 ¼ teaspoons dried yeast
1 cup warm water

Topping

½ cup warm water
2 tablespoons baking soda
coarse salt (sea salt, for example)
2 tablespoons unsalted butter, melted OR about a tablespoon of olive oil

If you want to make sweet pretzels rather than savoury/traditional pretzels, replace the coarse salt topping with a mixture of cocoa, cinnamon and a little icing sugar.

Process

Place all of the dough ingredients into a bowl, and beat till well-combined. Knead the dough, for about 5 minutes, till it's soft, smooth, and quite slack.
Flour the dough in a bowl, cover and allow it to rest for 30 minutes.
Preheat your oven to 240°C (fan forced, 260c fanless).
Prepare two baking sheets/trays by spraying them with oil spray, or lining them with baking paper.
Transfer the dough to a lightly greased work surface, and divide it into eight equal pieces (about 70g each). Allow the pieces to rest, uncovered, for 5 minutes.
While the dough is resting, combine the 1/2 cup warm water and the baking soda, and place it in a shallow bowl. Make sure the baking soda is thoroughly dissolved; if it isn't, it'll make your pretzels splotchy.
Roll each piece of dough into a long, thin rope (about 70cm long), and twist each rope into a pretzel. Dip each pretzel in the baking soda wash (this will give the pretzels a nice, golden-brown color), and place them on the baking sheets. Sprinkle lightly with salt (or sweet pretzel mix outlined above). Allow them to rest, uncovered, for 10 minutes.
Bake the pretzels for 7 to 8 minutes, or until they're golden brown, reversing the baking sheets halfway through.
Remove the pretzels from the oven, and brush them thoroughly with the melted butter (or oil).

Eat the pretzels warm, or reheat them in an oven or microwave.

YumML for this recipe

Facebook Chat over XMPP using OAuth2

paul@theleagueofpaul.com (Paul Jenkins) — Sat, 26 Nov 2011 00:00:00 +1100

Unlike the MSNXMPP posts, there isn't a huge code dump in this post. Working code is up on GitHub for the XMPP Authenticator and OAuth2Helper

Like Messenger, Facebook has an XMPP gateway into their Chat system. Unlike Messenger though, Facebook XMPP is fairly mature and has multiple forms of authentication available - namely DIGEST-MD5 and X-FACEBOOK-PLATFORM. DIGEST-MD5 is fairly straightforward and isn't the focus of this post but it should be pointed out that most XMPP clients are capable of DIGEST-MD5 as it is a standard auth mechanism that relies on the username and password. This is good for Facebook support - as their docs point out, you can use DIGEST-MD5 when the client isn't even aware of Facebook.

OAuth2

The main reasons I see for using X-FACEBOOK-PLATFORM are

You're building a Facebook chat client that also uses other Facebook data, so you want access with a single login and/or
you don't want to store username/passwords.

Facebook were one of the first (if not the first?) major sites to adopt OAuth2, moving away from their custom token based API. The url for beginning OAuth2 requests is

https://www.facebook.com/dialog/oauth?client_id=<CLIENTID>&redirect_uri=<REDIRECT>&scope=<SCOPE>&display=touch&response_type=token"

If you're developing a desktop or mobile app that can control the browser/have an embedded browser instance, you're encouraged to use https://www.facebook.com/connect/login_success.html as the redirect uri.

For scope, you use comma separated values rather than space separated values that Messenger uses. At a minimum, you want access to xmpp_login and unless you want to refresh it every hour, offline_acccess too. If you're building a Facebook app, this is a good time to add those additional permissions. Your scope string should look something like

offline_access,xmpp_login

On success, you'll be redirected to that redirect uri with a #access_token=.. appended. Handling it is exactly the same as handling Messengers implicit flow.

webBrowser.Navigate(<FACEBOOK URL>);
webBrowser.LoadCompleted += (s, e) => 
{
    if (!e.Uri.Fragment.Contains("access_token"))
        return;

    var responseAll = Regex.Split(e.Uri.Fragment.Remove(0, 1), "&");
    for (var i = 0; i < responseAll.Count(); i++)
    {
        var nvPair = Regex.Split(responseAll[i], "=");

        if (nvPair[0] != "access_token") 
            continue;

        var accessToken =  nvPair[1];
    }
}

I think once I've nutted out Google's OAuth2 XMPP flow, I'll create a library of helpers for all three - there are enough differences that they all need customisation, but enough similarities that based helpers would be... helpful.

X-FACEBOOK-PLATFORM

Like X-MESSENGER-OAUTH2, X-FACEBOOK-PLATFORM uses OAuth2 tokens and requires an embedded webbrowser client side to process. Unlike X-MESSENGER-OAUTH2, it requires a bit of extra processing - the client must issue a request, server issues a challenge, then finally the response.

Just like any other XMPP implementation, the auth mechanisms will appear in the 'stream features' when initially connecting to chat.facebook.com.

<stream:features>
    <mechanisms xmlns="urn:ietf:params:xml:ns:xmpp-sasl">
        <mechanism>X-FACEBOOK-PLATFORM</mechanism>
        <mechanism>DIGEST-MD5</mechanism>
    </mechanisms>
</stream:features>

The Challenge

To begin the challenge process, you need to send what type of auth (X-FACEBOOK-PLATFORM) like this

<auth mechanism='X-FACEBOOK-PLATFORM' xmlns='urn:ietf:params:xml:ns:xmpp-sasl' />

It's the same mechanism we sent with Messenger, except without contents, and it just starts the process. Next up the server will send a challenge. Challenges are a standard part of XMPP, so this isn't anything unusual. The only thing unusual is that it isn't a JSON or XML packet, but instead an "http-url-like" string thats URL and Base64 encoded.

<challenge xmlns="urn:ietf:params:xml:ns:xmpp-sasl">dmVyc2lvbj0xJm1ldGhvZD1hdXRoLnhtcHBfbG9naW4mbm9uY2U9OEQwRkJGRDdBQTY5RkI0REJDRjc2MzEzNkY2NjFDRUM=</challenge>

Decoded (Base64 the Url decode), that challenge looks something like:

version=1&method=auth.xmpp_login&nonce=8D0FBFD7AA69FB4DBCF763136F661CEC

You can discard the version (it'll always be 1), but the method and nonce are important. I'd say that the method will always be auth.xmpp_login, but I can't guarantee it and the documentation says to extract it.

The Response

In response, you must build up a similar string, then Base64 encode it. For what it's worth, Base64 is something XMPP dictates, not Facebook.

method=auth.xmpp_login&api_key=<APIKEY>&access_token=<ACCESSTOKEN>

To do that, I used the following code

private string BuildResponse(string method, string nonce)
{
    var requestString = new StringBuilder();
    requestString.AppendFormat("method={0}", method);
    requestString.AppendFormat("&api_key={0}", _apiKey);
    requestString.AppendFormat("&access_token={0}", Connection.UserPassword);
    requestString.AppendFormat("&call_id={0}", "0");
    requestString.AppendFormat("&v={0}", "1.0");
    requestString.AppendFormat("&nonce={0}", nonce);

    var response = EncodeTo64(requestString.ToString());
    return response;
}

static public string EncodeTo64(string toEncode)
{
    byte[] toEncodeAsBytes = Encoding.ASCII.GetBytes(toEncode);
    string returnValue = System.Convert.ToBase64String(toEncodeAsBytes);
    return returnValue;
}

Once encoded, send the response like so

<response xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>bWV0aG9kPWF1dGgueG1wcF9sb2dpbiZhcGlfa2V5PTxBUElLRVk+JmFjY2Vzc190b2tlbj08QUNDRVNTVE9LRU4+</response>

And (hopefully!) you should get back a success followed by regular XMPP roster/etc.

<success xmlns="urn:ietf:params:xml:ns:xmpp-sasl"/>

Caveats

Facebook Chat is not actually an XMPP server - or something along those lines. There is the gateway/translation process, but like Messenger it doesn't operate directly on XMPP so there are some "lost in translation" issues.

It handles plaintext messages only (not HTML)
XEP-0085 not XEP-0022 for typing notifications
vCards via XEP-0054
Just like Messenger you can't add/remove contacts via Roster management - you'd need to use the Facebook Graph API

There are a few other things explicitly not supported, but basically it can be summed up as: if it's not on this list, it probably won't work. XMPP Core is supported, but not too much else.

Is this a good thing?

At the end of my first Messenger/Xmpp post, I pondered was that implementation a good thing, concluding that 'yes but mostly no'. Facebook doesn't suffer the same response

Facebook XMPP documentation was actually really useful
Addition of offline_access scope means no renewing of tokens
Fallback to DIGEST-MD5 allows non-Facebook aware apps to connect
There is a roadmap (for Facebook APIs in general)
We know there won't ever be VoIP/file transfer (a 'no' is better than not knowing) as Skype handles VoIP/Video.

Knowing what limitations are in place allows a more consistent app. Knowing that some of the data can be replaced with other API calls is also helpful. Messenger is a chat client/network trying to be a social network - the "homepage" of live.com is useless relying on data aggregation and GUID's for profile urls. Facebook is a social network trying to be a chat network and succeeding relatively well at it.

Live Messenger over XMPP Refresh Tokens

paul@theleagueofpaul.com (Paul Jenkins) — Thu, 24 Nov 2011 00:00:00 +1100

While I was previously unable to get refresh tokens working in Live Messenger over XMPP, I've finally figured it out. To be fair, the documentation did have it tucked away under the Reference/OAuth 2 section, not under XMPP or Messenger sections but really, I should have just RTFM a little bit better.

There are two types of "authorisation flow" - implicit and code and the difference starts with the initial request. Only code flow can get refresh tokens, implicit flow is designed as short lived (one hour) access. Having response_type=token in the url starts implicit flow, but having response_type=code starts code flow.

Using Code Flow

Where we previously had

https://oauth.live.com/authorize?client_id=CLIENTID&redirect_uri=https://oauth.live.com/desktop&response_type=token&scope=SCOPES

It should now be

https://oauth.live.com/authorize?client_id=CLIENTID&redirect_uri=https://oauth.live.com/desktop&response_type=code&scope=SCOPES

If you want a refresh token, you must have wl.offline_access in your scopes. Ideally, scopes should look like

scope=wl.basic%20wl.offline_access%20wl.messenger

Implicit flow (as the name implies) restricts access and thus doesn't need to do as thorough checking of who you say you are. You still can't get in without user authorisation and the proper ClientID, but a great deal less processing is required. By contrast code flow has two steps of confirmation and require your client secret code as well.

In implicit flow, once you have directed the user to the login url and they've granted access, you're redirected instantly to your redirect_uri with the auth token attached in the uri fragment. With code flow, you're redirected to your redirect_uri but get back a code used to then confirm you are who you say you are - not the actual auth token. If you're using the default redirect_uri, that url will look something like https://oauth.live.com/desktop?code=<code>.

At this point you can close the browser view from the user, as they don't need to interact with it anymore. Your code, however, still needs to make one final web call to

https://oauth.live.com/token?client_id=CLIENT_ID&redirect_uri=REDIRECT_URL&client_secret=CLIENT_SECRET&code=AUTHORIZATION_CODE&grant_type=authorization_code

You'll then get back a JSON payload that looks like

{
    "access_token" : "a_really_long_string",
    "authentication_token"  :"another_really_long_string",
    "expires_in" :3600,
    "refresh_token" : "final_long_string",
    "scope" : "wl.basic wl.messenger wl.offline_access",
    "token_type" : "bearer"
}

Finally! We have our refresh token! Remember, you don't have to reconnect every hour, it's just that new connections after the token expires (DateTime.Now.Add(new TimeSpan(1, 0, 0))) will need the access token 'refreshed' first, and to do that, you have to send another web request to

https://oauth.live.com/token?client_id=[YOUR_CLIENT_ID]&client_secret=[YOUR_CLIENT_SECRET]&redirect_uri=REDIRECT_URL&grant_type=refresh_token&refresh_token=[REFRESH_TOKEN]

Again you'll get back a JSON payload that looks almost identical to the one above, just missing the authentication_token.

Coding it all

These changes make my previous OAuth2Helper somewhat less useful. It'll still work, just in less useful situations. Using parts of the code from Microsoft's LiveSDK on GitHub I cobbled together a new helper library that should handle it from start-to-finish. This should take on no external dependencies, but if you were to start using the rest of the LiveSDK API, I'd recommend switching to something like RestSharp and JSON.NET.

I've taken the effort to make sure all scopes are available in the enum, most of them don't need to be used unless you're using the REST API as well. Many of the scope options are supersets of previous scopes, for example ContactsBirthday gives access to your contacts birthday and the logged in users birthday, whereas Birthday just gives the latter. Information is up on MSDN about all the permissions each scope gives.

I also realise this isn't ideal - no error checking nor is it asynchronous - it is meant as demo code to prove a point, if somebody is actually interested in this, I'm happy to lend a hand to make it more usable.

[DataContract]
public class OAuthToken
{
    [DataMember(Name = OAuthConstants.AccessToken)]
    public string AccessToken { get; set; }

    [DataMember(Name = OAuthConstants.RefreshToken)]
    public string RefreshToken { get; set; }

    [DataMember(Name = OAuthConstants.ExpiresIn)]
    public string ExpiresIn{get; set;}

    [DataMember(Name = OAuthConstants.Scope)]
    public string Scope { get; set; }
}

public static class OAuthConstants
{
    public const string ClientID = "client_id";
    public const string ClientSecret = "client_secret";
    public const string Callback = "redirect_uri";
    public const string ClientState = "state";
    public const string Scope = "scope";
    public const string Code = "code";
    public const string AccessToken = "access_token";
    public const string ExpiresIn = "expires_in";
    public const string RefreshToken = "refresh_token";
    public const string ResponseType = "response_type";
    public const string GrantType = "grant_type";
    public const string Error = "error";
    public const string ErrorDescription = "error_description";
    public const string Display = "display";
}   

[Flags]
public enum Scope
{
    [Description("wl.basic")]
    Basic = 1,

    [Description("wl.messenger")]
    Messenger = 2,

    [Description("wl.offline_access")]
    Offline = 4,

    [Description("wl.signin")]
    Signin = 8,

    [Description("wl.birthday")]
    Birthday = 16,

    [Description("wl.calendars")]
    Calendars = 32,

    [Description("wl.calendars_update")]
    CalendarsUpdate = 64,

    [Description("wl.contacts_birthday")]
    ContactsBirthday = 128,

    [Description("wl.contacts_create")]
    ContactsCreate = 256,

    [Description("wl.contacts_calendars")]
    ContactsCalendars = 512,

    [Description("wl.contacs_photos")]
    ContactsPhotos = 1024,

    [Description("wl.contacts_skydrive")]
    ContactsSkydrive = 2048,

    [Description("wl.emails")]
    Emails = 4096,

    [Description("wl.events_create")]
    EventsCreate = 8192,

    [Description("wl.phone_numbers")]
    PhoneNumbers = 16384,

    [Description("wl.photos")]
    Photos = 32768,

    [Description("wl.postal_addresses")]
    PostalAddresses = 65536,

    [Description("wl.share")]
    Share = 131072,

    [Description("wl.skydrive")]
    Skydrive = 262144,

    [Description("wl.skydrive_update")]
    SkydriveUpdate = 524288,

    [Description("wl.work_profile")]
    WorkProfile = 1048576,

    [Description("wl.applications")]
    Applications = 2097152,

    [Description("wl.applications_create")]
    ApplicationsCreate = 4194304
}

public static class OAuth2Helper
{
    public static Uri GenerateRequestUrl(string clientId, Scope scopes, string type="token", string callback="https://oauth.live.com/desktop", string display = "touch")
    {
        string scopeString = "";
        var y = Enum.GetValues(typeof(Scope)).Cast<Scope>();
        foreach (var s in y)
        {
            if ((scopes & s) == s)
                scopeString += GetDescription(s) + "%20";
        }

        return new Uri(String.Format(@"https://oauth.live.com/authorize?client_id={0}&display={2}&redirect_uri={4}&response_type={3}&scope={1}", clientId, scopeString, display, type, callback));
    }

    public static OAuthToken RefreshToken(string clientId, string clientSecret, string refreshToken, string callback = "https://oauth.live.com/desktop")
    {
        var wc = new WebClient();
        var url = string.Format("https://oauth.live.com/token?client_id={0}&redirect_uri={1}&client_secret={2}&refresh_token={3}&grant_type=refresh_token", clientId, callback, clientSecret, refreshToken);
        var response = wc.DownloadString(url);
        var ms = new MemoryStream(Encoding.Unicode.GetBytes(response));
        var serializer = new DataContractJsonSerializer(typeof(OAuthToken));
        return serializer.ReadObject(ms) as OAuthToken;
    }

    public static string CodeFromUriResponse(Uri response)
    {
         if (!response.Query.Contains("code"))
            return null;

        var nvPair = Regex.Split(response.Query.Substring(1), "=");
        return nvPair[0] == "code" ? nvPair[1] : null;
    }

    public static string AccessTokenFromUriResponse(Uri response)
    {
        if (!response.Fragment.Contains("access_token"))
            return string.Empty;

        var responseAll = Regex.Split(response.Fragment.Remove(0, 1), "&");
        return (from t in responseAll
                select Regex.Split(t, "=") into nvPair
                where nvPair[0] == "access_token"
                select nvPair[1]).FirstOrDefault();
    }

    public static OAuthToken AuthCodeToToken(string clientId, string clientSecret, string auth, string callback = "https://oauth.live.com/desktop")
    {
        var wc = new WebClient();
        var url = string.Format("https://oauth.live.com/token?client_id={0}&redirect_uri={1}&client_secret={2}&code={3}&grant_type=authorization_code", clientId, callback, clientSecret, auth);
        var response = wc.DownloadString(url);
        var ms = new MemoryStream(Encoding.Unicode.GetBytes(response));
        var serializer = new DataContractJsonSerializer(typeof(OAuthToken));
        return serializer.ReadObject(ms) as OAuthToken;
    }

    public static string GetDescription<T>(T value) where T : struct
    {
        string name = value.ToString();

        object[] attrs =
            value.GetType().GetField(name).GetCustomAttributes(typeof(System.ComponentModel.DescriptionAttribute), false);

        return (attrs.Length > 0) ? ((System.ComponentModel.DescriptionAttribute)attrs[0]).Description : name;
    }

    public static T GetEnumFromDescription<T>(string value)
    {
        if (string.IsNullOrEmpty(value))
        {
            throw new ArgumentException("value must be non-empty");
        }

        var field = typeof(T).GetFields().FirstOrDefault(f =>
        {
            var attrs = f.GetCustomAttributes(typeof(System.ComponentModel.DescriptionAttribute), false);

            if (attrs.Length > 0)
            {
                if (((System.ComponentModel.DescriptionAttribute)attrs[0]).Description == value)
                {
                    return true;
                }
            }

            return false;
        });

        if (field != null)
        {
            return (T)field.GetValue(null);
        }
        else
        {
            return (T)Enum.Parse(typeof(T), value);
        }
    }
}

Usage

To start the OAuth2 process

webBrowser.Navigate(OAuth2Helper.GenerateRequestUrl("clientid", Scope.Messenger | Scope.Offline, "code"));

To get the token back

webBrowser.LoadCompleted += (s, e) => 
{
    var code = OAuth2Helper.CodeFromUriResponse(e.Uri);
        if (!string.IsNullOrEmpty(code))
        {
            var token = OAuth2Helper.AuthCodeToToken("clientid", "secret", code);
        }
}

Where does that leave us?

While refresh tokens are annoying, using it correctly does solve one of the major issues I had with MSNXMPP. However, this doesn't solve the "idle" (XEP-0199) issue that caused the connection to be dropped, nor non-standard Roster management.

Live Messenger over XMPP

paul@theleagueofpaul.com (Paul Jenkins) — Mon, 21 Nov 2011 00:00:00 +1100

Microsoft's Windows Live Messenger uses a custom protocol known as "MSNP", now up to at least version 21 of the protocol. Every client that supports Messenger - up until recently - has used a version of this protocol. The only problem with MSNP is that to use it, you need to reverse engineer Microsoft's work and given significant parts of it are encrypted, it results in a cat-and-mouse game of trying to decrypt, understand, and then support the new features, often resulting in bungled implementations.

Recently, however, Microsoft announced that they'd have XMPP access to Messenger contacts/IM. Does this mean you can plug Messenger server details into any XMPP client? Not exactly. It does mean with a little bit of modification, you could support multiple IM networks via a single client a lot easier - working on one protocol/plugin (even with a few variants) is easier than maintaining netcode for two distinct protocols.

Authorization

Instead of plugging in your username and password (SASL-PLAIN or SASL-DIGEST-MD5), Messenger over XMPP uses OAuth2 and a custom SASL method - X-MESSENGER-OAUTH2. For reference, Google have X-GOOGLE-TOKEN and Facebook X-FACEBOOK-PLATFORM for their XMPP implementations, but they both have fallbacks to allow you to use your username/password. OAuth2 is significantly easier than OAuth1 to consume - you won't need any encryption or OAuth helper libraries to handle it as there isn't any secret/token generation required to consume.

First you need to sign up and "create" an application through the Live Connect control panel - there isn't any cost, its just a simple registration for a Client ID.

Then you need to use a browser control (or browser window with redirect back to a webapp) to display

https://oauth.live.com/authorize?client_id=CLIENTID&redirect_uri=https://oauth.live.com/desktop&response_type=token&scope=SCOPES

At a minimum, you need the scope to be set to wl.messenger, but wl.offline_access will work too (either by itself, or combine the scopes separating them with a space). CLIENTID in this case is the Client ID generated when you signed up and created your Live Connect app. Once the user logs in and authorises, you'll be redirected to a page with the query fragment (that is, stuff after a #) containing access_token. You need to store that token.

Hint: if you want a finger-mash friendly page, make sure you include display=touch.

Show me the (C#) code!

Whether you use WinForms, WPF, WP7 or something else, you need to generate a request url to pass to a browser, and peek at the response Uri.

public static class OAuth2Helper
{
    public static Uri GenerateRequestUrl(string clientId, string scope, string display = "touch")
    {
        return new Uri(String.Format(@"https://oauth.live.com/authorize?client_id={0}&display={2}&redirect_uri=https://oauth.live.com/desktop&response_type=token&scope={1}", clientId, scope, display));
    }

    public static string AccessTokenFromUriResponse(Uri response)
    {
        if (!response.Fragment.Contains("access_token"))
            return string.Empty;

        var responseAll = Regex.Split(response.Fragment.Remove(0, 1), "&");
        return (from t in responseAll 
                select Regex.Split(t, "=") into nvPair 
                where nvPair[0] == "access_token" 
                select nvPair[1]).FirstOrDefault();
    }
}

To start the OAuth2 process:

webBrowser.Navigate(OAuth2Helper.GenerateRequestUrl("12354", "wl.messenger"));

To get the token back:

webBrowser.LoadCompleted += (s, e) => 
{
     if (!e.Uri.Fragment.Contains("access_token")) 
     {
        var authToken = OAuth2Helper.AccessTokenFromUriResponse(e.Uri);
     }
}

SASL

It took a little while for me to get the hang of it as I was implementing it from scratch, but custom SASL implementations can be very straight forward. After the initial XMPP connection is established, you'll get back a "features" list from the server that will look similar to this (although without the linebreaks and indentation)

<stream:features xmlns:stream="http://etherx.jabber.org/streams">
    <starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls">
        <required />
    </starttls>
    <mechanisms xmlns="urn:ietf:params:xml:ns:xmpp-sasl">
        <mechanism>X-MESSENGER-OAUTH2</mechanism>
    </mechanisms>
</stream:features>

If that doesn't make sense to you, TLS/SSL is required, and X-MESSENGER-OAUTH2 is the only SASL mechanism that is supported - you cannot use MD5-DIGEST or PLAIN auth. Your response should be

<auth mechanism='X-MESSENGER-OAUTH2' xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>OAUTH_TOKEN_GOES_HERE</auth>

And if that was a valid token, you'll receive back <success xmlns="urn:ietf:params:xml:ns:xmpp-sasl" /> which (should) be followed by roster and presence information. Make sure that you Uri decode the token!. Other reasons why it might reject your token include an expired token (more on that below), insufficient privledges (ie, you set the scope to wl.basic) or a revoked token.

Most XMPP/SASL connect libraries will have a way to pass in a name (X-MESSENGER-OAUTH2) and string/token.

Limitations

According to the documentation

The Windows Live Messenger Extensible Messaging and Presence Protocol (XMPP) service supports only these extensions as defined by the XMPP Standards Foundation, with partial support for these extensions as noted.

RFC6120: XMPP: Core
RFC6121: XMPP: Instant Messaging and Presence. Roster management is not supported.
XEP-0054: vcard-temp. The Messenger XMPP service supports fetching vCards but doesn't support updating vCards.
XEP-0085: Chat State Notifications.
XEP-0203: Delayed Delivery

The emphasis is mine, but it highlights how this is a partial solution to using XMPP to connect to Messenger - there is no VoIP, there is no video, there is no file transfer. Even forgetting those parts (most third party implementations of MSNP lack those three features anyway), lack of roster management and only partial vCard support is problematic - it isn't as simple as an authentication layer being put in front to get it to work, XMPP roster management (that is, adding/removing contacts) would have to be done via the REST API (if those exist - I haven't looked).

Currently I'm experiencing "idle" issues - after 1-2 minutes of no traffic, the connection is closed by the other end. Is this an issue with their XMPP server? XEP-0199 isn't specifically mentioned as supported (thats "ping/pong" in XMPP standards) although it does have references throughout RFC4120, but it's only the Messenger XMPP server that drops the connection (against my code that is).

Token Expiry

This is a big one, and fundamentally breaks the way any existing XMPP client works. Unlike OAuth1, OAuth2 tokens are designed to be short lived and in this case, they expire after an hour. This doesn't mean the connection is dropped after an hour, it just means next time you go to log in, if it's been greater than an hour, you'll need to get a new token.

Facebook uses OAuth2 for it's "Graph Protocol", so how does that get around mobile/desktop apps that don't renew? By requesting offline_access during the initial OAuth2 stages, that sets the token to never expire. Access can still be revoked, but the token won't timeout.

Tokens can be renewed, the SDK documents tell me, but I haven't figured out how. You're suppose to send a request to

https://oauth.live.com/token?client_id=[CLIENTID]&client_secret=[CLIENTSECRET]&redirect_uri=https://oauth.live.com/desktop&grant_type=refresh_token&refresh_token=[REFRESHTOKEN]

The client ID and secret are found on the Live Connect control panel, but I'm not sure what the refresh token is - neither (access_token and authentication_token) tokens returned by the initial authorisation process seem to work.

Ultimately, I think the Facebook approach of having long-lasting tokens when required would have been better in this situation.

Is this a good thing?

While I'm happy to see a more standard IM protocl AND a standard authentication protocol be adopted/permitted, I'm not entirely sold on this particular implementation of XMPP.

There isn't a (public) roadmap for future features (if there will be any),
the changes required aren't as simple as the initial authentication,
the documentation and samples don't actually cover .NET (and I don't really feel like setting up a Java dev environment just to see if their samples are "stable" on Java),
Token expiry reaaaallly sucks for any compatibility with existing XMPP implementations

This experiment wasn't a complete loss. I'll still be using MSNPSharp, but the changes made to Hanoi (our XMPP library) and MahChats were needed anyway - that is, inheriting from a base Xmpp plugin to create preconfigured "profiles" (ie, Facebook, GTalk then generic XMPP/Jabber) and the code Hanoi was based on (BabelIM) didn't allow custom SASL mechanisms to be easily plugged in - they had to be hard coded in.

MahApps.Metro 0.3 Release

paul@theleagueofpaul.com (Paul Jenkins) — Mon, 07 Nov 2011 00:00:00 +1100

Exciting times for MahApps.Metro - over 100 downloads via Nuget, more sightings in the wild, a new contributer and a move to GitHub. And finally, version 0.3 has now been released and pushed to NuGet.

What's new in 0.3?

Combined MahApps.Metro.Controls into MahApps.Metro for a single library
This is considered a breaking change but thankfully it isn't horrible to fix and it's the only breaking change. Previously MahApps.Metro.Controls were in a separate assembly, but they've been combined into a single assembly. The namespaces are the same, so it will just be project references that need to change.

xmlns:Controls="clr-namespace:MahApps.Metro.Controls;assembly=MahApps.Metro.Controls"

will become

xmlns:Controls="clr-namespace:MahApps.Metro.Controls;assembly=MahApps.Metro"

New controls

Panorama
MetroImage
Tile

Added Theme Manager
Previously you had to roll your own theme/accent switching code, but we've now included in a static ThemeManager class to handle that.

Using one of the built-in accents

ThemeManager.ChangeTheme(this, ThemeManager.DefaultAccents.First(a => a.Name == "Red"), Theme.Light);

The built in accents are Red, Blue, Green and Purple.

Using your own accent

var myAccent = new Accent("MyAccent", new Uri("pack://application:,,,/My.App;component/MyAccent.xaml"));
ThemeManager.ChangeTheme(this, myAccent, Theme.Dark);

This does not persist theme changes - you'll need to handle that yourself.

And various bug fixes and missing styles

Additional controls styled:
- Slider
- GridView
Fixed button hover and pressed state
Fixed TabItem focus issues
Fixed Dark -> Light theme transition issues

Show Me The Demo!

You can grab the demo app from source or now you can install it via ClickOnce, or watch the short video below demoing the new controls