#cernsso

First thing was to move it to use the new universal projects and PCL's. They have advanced significantly since I first wrote this code. In particular, it is now time to move to Windows.Net.Http, which involves a lot of changes. In particular, how the credentials are used.

The basic things are the same (see previous posts on CERNSSO). In particular, the fact that a Windows App has only the local cert store. What is nice, now, is that also exists on Windows Phone - so with 8.1 they are identical finally. It wasn't possible to do anything with certificate stores on WP previously.

But this makes me wonder. Why can't I add the cert and make the web request, allow redirects, and let the underlying system (which mimics a browser) just work? That would be a lot simpler than doing what I'm currently doing. Testing that is going to require some effort. :-)

Found some example code on accessing certificates and associating them with a request in the windows runtime here.

And finally, started working on the View's. Been putting that off for a number of reasons - mostly fear of UI.

Now have a reasonable add paper UI on both the store and phone app's.

The button for the app paper ui on the phone looks like ass for some reason. Mostly, it is really tiny and it also the text just isn't there.

To get the button to work correctly, I had to explicitly wire up the command(Command = "{Binding AddButtonCommand}"). It would be nice to find out if it is possible to make that a default behavior or not.

And playing around I discovered a basic error. When you add a bogus paper (id = 22, for example, which is deleted) two things happen:

The AddButton becomes enabled

The github project is called CERNSSO.

Portability across three platforms is not easy! A few things I've had to deal with here:

Unit testing is not the same across all three platforms. First, the namespace is different. Second, only the desktop has a ExpectedException attribute - so I've had to move to common on everything else.

WebRequest turns out to be the old way of doing things. Everything needs to be moved over to HttpClient in order to support as many platforms as we can. For WindowsPhone you have to get a MS nuget package (in both the library and the test project). That should make my eventual nuget spec package... interesting.

And there is a new helper object that represents the content of an http request that looks very nice: FormUrlEncodedContent. I just give it a list of name-value pairs, and it does everything else. Unfortunately, it is a little weird as it mixes up content as well as headers and cookies.

To provide a client certificate on the desktop you need to explicity create the WebRequestHandler object - something unique to that platform. For WindowsStore you need to load the CERT into a per-app store, and then tell it to automatically load those kinds of certs. In short, it there is some per-platform hackery going on.

This was implemented as a few source files, with if def's for platform differences.

I also updated the main testing stuff I'd done to load this package.

And it is published to nuget! Woo! First tangible result from this hack.

There are still a few things to do to finish up:

Push the source code and pdb for the release build to enable others to debug.

Test against indico and other things.