Architecture Chat #33

Short writeup for the last architecture chat - we had 7 (or was it 8) attending the 11th September 2008 chat - including a couple of intergenites who made the arduous journey over the bridge (always nice to see some new faces!).

Topics of discussion included:

  • Teched 2008 NZ
  • Lack of developers in New Zealand, and problems/opportunities with current graduates emerging from various institutes.
  • Working for Microsoft, the buy-up of blogging talent.
  • The push to improve the profile of bloggers in NZ.
  • Bloggers Dinner, Scott Hanselman etc.
  • Google chrome.
  • PDC 2008.
  • Managed Extensibility Framework, what it is/is not - though I don't think of any us are quite sure yet - perhaps Hammet needs to do some videos? ;o)
  • Generic Natural Language DSL's and interesting ideas like Intellisense for a Natural Language DSL's (I found this interesting, not sure anyone else did...)

It was a bit rambling so by the end of it I think most of us were not really sure just what we'd talked about.

As per usual previous write-ups can be found here on the wiki.  There's also a group on
for those who have attended in the past (or plan to attend in the future? perhaps) so you can connect with other participants.

The next chat is this Thursday - 25th September - I'll post a reminder tomorrow - and if anyone has any topic suggestions please email or leave a comment on this post.

Read More

Writing OpenSocial applications in ASP.Net

I've had some requests from different ASP.Net developers writing
applications for the OpenSocial platform
lately wanting to use DevDefined.OAuth
to validate signed requests with a public certificate - so I've put
together a little example to help get people started.

What are we trying to do?

So first of let's review how the process works and what we're
trying to achieve.

alt="OAuthOpenSocialRequestFlow.PNG" border="1" height="112" widthsrc="692" />

Basically as a developer for the OpenSocial platform you will be
writing gadgets - these gadgets are generally defined in an XML
document providing information about your application and a chunk
of html content which will be rendered into an IFrame to kick the
application off (including javascript functions etc. to fetch
remote content) - to work around spoofing issues and to avoid
cross-scripting issues your gadget can use pre-canned functions in
the open-social java-script library to make requests to your own
services, which to the developer appear to be a direct request to
their site.

Under the hood the the requests are instead made to the opensocial
host platform, which acts as a proxy passing the request onto your
application - at this point the platform employes OAuth (though
without any 3-pronged delegate authority being established) to sign
the request using a x509 Certificate (i.e. the RSA-SHA1 signature
method) at which point it calls your application with the signed
request and passed on response back to the calling gadget.

The main goals in signing the request (in so far as I can tell) are
to ensure it hasn't been tampered with, spoofed and provide a Nonce
and timestamp so you can void replay attacks - something that using
SSL alone would not prevent.

Because a lot of the mechanics of OAuth itself is being
circumnavigated, it's much simpler to verify the signature is

Gadget XML

Right - onto the code - Let's take a look at the Gadget XML


Basically the XML for the gadget is a chunk of metadata and finally
some actual content for the gadget itself - notice that it regsters
a handler to run on load of the gadget, and that it's then making a
request to the url and
render the response in the inner HTML of the container div DOM

The key to this being an OAuth signed request is the 5th
line of the makeRequest function:

params[] =;

So far so good - uploading your application is pretty easy - but
is generally platform specific - if you wanted to try this out on
Friendster then just head to
click on the OpenSocial tab and follow the instructions - the
approach is to save your gadget definition as an XML file
somewhere, then publish that XML document on the web and then
create an application in your open social host of choice and
direct th it to the XML files location.  It takes all of a
minute to do.

ASP.Net Application (Provider)

Now for the application itself - first off you need to locate and
download the provided public key (certificate) for the social
platform host and either store it on the filesystem or in the
case of this demo we'll just store it as a string, like so:

public class OpenSocialCertificates
private const string _friendsterCertificate =

public static X509Certificate2 FriendsterCertificate
get { return new X509Certificate2(Encoding.ASCII.GetBytes(_friendsterCertificate)); }

It's worth noting that the certificates can be changed at any
time - but fair warning will be given (according to the document)
- and that the location (url) of the certificate is actually
included as a parameter in the requests the host makes to your
application (xoauth_signature_publickey) - so it's fairly
trivial to implement a caching scheme to automatically pull down
and update the certificate if it has changed.

Now that we have the certificate we just need to validate the
request, in this cause I'm just going to check it's been signed -
I've left validating timestamps and nonces out of the example, as
these tend to be propritary to the app your building, but both
are easy to implement.

public partial class SocialService : Page
protected void Page_Load(object sender, EventArgs e)

// now handle the request...

private void ValidateWithDevDefinedOAuth()
OAuthContext context = new OAuthContextBuilder().FromHttpRequest(Request);
var signer = new OAuthContextSigner();
var signingContext = new SigningContext {Algorithm = OpenSocialCertificates.FriendsterCertificate.PublicKey.Key};

if (!signer.ValidateSignature(context, signingContext))
throw new OAuthException(context, OAuthProblems.SignatureInvalid, "check certificate is still valid");
catch (OAuthException authEx)

The process is basically using the OAuthContextBuilder
class to construct a context (which is used to calculate a
signature base) from the current pages request.  It then
constructs a signer (used for signing requests and checking their
signatures i.e. validation) and a signing context, which is used
to provide additional information to the signer, such as the
public key of the friendster certificate.

We then invoke ValidateSignature to ensure the signature
is valid - if not we throw an exception.

Finally if an OAuthException is thrown we catch it and render
it's report to response stream and close it - this provides
diagnostic information as per the OAuth problem
reporting extension

Hope this has been useful to some people out there - BTW I'm no
OpenSocial expert, so please direct general OpenSocial questions
to the apropriate google groups, I can only help with OAuth
library questions.

Problems with Friendster Requests

As a side note - for anyone who's tried writing an OpenSocial
application using DevDefined.OAuth to validate request signatures
they may have found it didn't work! This was a result of
Friendster appending an ampersand (&) to the end of the query
string on the Url, which was causing the signature base to be
incorrect (I'm not sure if this is an issue for other OpenSocial
implementations) - The code now checks for this and removes it if
discovered - and signature validation works as expected.

Read More

2008-09-09 - Architecture chat tomorrow (Thursday)

Architecture chat tomorrow, Thursday - 11th September @
11:30am onwards.

Some possible topics / things that have caught my eye lately:

  • Google Chrome - V8's great,
    flash works but our "anywhere" platform silverlight wont, and
    apparently not until chrome gains market share... hmmm.

  • TechEd Roundup - including the infamous keynote.
  • Teched Bloggers Dinner report and related "NZ blogging push"
    for the next year.
  • C# Library for controlling EC2 Instances (via David)
  • Generic Natural Language DSL (via ayende)

  • Managed Extensibility Framework (MEF) Preview 2 vs. Mono.Addins.

  • Resharper

  • Spec/BDD frameworks (MSpec,
    StoryQ etc.)
  • Monorail in the Cloud.

See you all there!

P.S. Information regarding the location and previous chat write-ups
can be found here.
Read More

ADVANCED-DOTNET is being retired...

Unfortunately the old ADVANCED-DOTNET
mailing list at DevelopMentor is being put down,
like an old but still on the odd occasion faithful dog. This
would be one of the first .Net mailing lists I ever really
latched onto (about 6 years ago...) and there have been some
pretty bright sparks on their since day one.

Hi all

We are currently undertaking an infrastructure review at DevelopMentor and
have realised that apart from this one list the listserv is not really used
any more. Unfortunately we cannot really justify maintaining the server for
this one list and so we have decided to retire the listserv.

I created this list as a moderated list six and a half years ago and so feel
a bit sad to see its passing, but the world has moved on from mail
reflectors to blogs, web forums and other discussion mediums.

We will be taking the server offline on the 30th September so you have a bit
of time to get anything you need from the archives

Thanks for your involvement over the last few years

Richard Blewett

I think what's more disappointing is that in turning it off they
certainly haven't spent much time thinking about an exit plan,
because there's no archive availability (the listserv is getting
turned off completely) or alternative place identified for list
participants to move to... I often think this is something that
needs to be thought about up front (and budgeted for, 
almost in some separate trust fund) especially as communities and
social platforms proliferate - it's a shame to see information

That said it looks like some of the long time readers of the
group are working to migrate the server away from develop mentor,
or to move onto this google
- be interesting to see where this goes.

On a side note I wonder how much sites like stack overflow will errode
the last remnants of mail-only technical mailing lists...
personally (while I've been beta testing it) I've found the stack
overflow concept doesn't really gel with me - but I can see it's
appeal to others - personally I prefer discussion over problem
"resolution" and the ability for a group to collectively choose
not to answer a problem (because it's but 2 clicks away on a
simple google search) - where as with the reputation system in
Stack overflow the simple/dumb/obvious questions are like crack
for the reputation kidies. 

On the same note, how much will stack overflow and similar
concepts errode organic blog discovery (which is normally while
someone is trying to find an answer to a question).... hmmm

Read More

Choice is good - another OAuth library for .Net emerges

You may recall a few months back I released an  OAuth library for .Net (which can be found here on google code) - at the time of writing that library the only other OAuth "solution" for .Net developers was a C# file containing some simple helper functions, that didn't even produce valid results in many cases, and the rather basic implementation as part of the restful chess/myspace example.

Well the guys at Madgex in the UK have now released their own OAuth.Net library.. for more details you can:

As for differences between the two implementations... from a 50K foot glance.
  • There's a dependency on the Windsor container when using the Madgex library (if you want to use it's out the box implementation / configuration examples etc.)
  • The Madgex library includes a http module for making a provider implementation easier when building web apps.
  • The madgex library appears to take a harder dependency on HttpRequest then the DevDefined library (but that's just a hunch, saw it in a few interface definitions, rather then some wrapper equivalent).
  • The madgex library looks a little more polished (i.e. xml docs) and has a configuration section.
  • The Madgex library features some niceities like Sliding window validation support (i.e. they only allow messages to be supplied where the timestamp falls within a certain time window of the server, and keep the list of previous nonces only for the
    period of that window - flushing nonces that are not longer required via a background thread - saving on the volume of nonces to record i.e. for replay attacks).  Of course it's an in-memory solution, so not suited to farms, but still cool.
  • Slightly less fluent consumer implementation, I prefer my libraries consumer implementation, but of course that's just me :P
  • Both libraries are under the MIT license.

All said and done it's a very sound effort, great work guys!

And it's awesome to have some choice emerging in this space.


Read More