How to use as an OpenID provider

by Matt 16. April 2009 17:39


One of the nice things about OpenID is that just about anyone can be an identity provider. Indeed, that’s pretty much the point.

OpenID is just a URL. Specifically, a URL that uniquely identifies you and that you and only you have control over.

You know, like your blog address.

So let’s make be an OpenID. Turns out, it’s dead easy.

1. Go and get an OpenID

What? Did you think we’d do the heavy lifting ourselves? No, no, no. Friends don’t let friends try and implement security protocols. Leave it to the professionals.

Put it this way – I don’t even want to have to get https working as a part of my blog, let alone implement OpenID security exchanges.

I used the guide available at Will Norris’ site to help make a choice of which 3rd party to help decide which to go for. As far as I can see, the two best choices are MyOpenID and MyVidoop. Both look like very good providers, offering just about everything – attribute exchange, personas - but I went with MyOpenID because they support logging in using CardSpace (we have history).

So, my OpenID is

2. But I thought you said you could use your blog address?!

Of course. OpenID supports delegation. This allows me to have an OpenID URL that delegates to another OpenID provider. In other words, when I try to log in to a site using this blog as an OpenID, this blog will actually delegate responsibility to the “real” OpenID provider, MyOpenID.

This is very easy to set up. You just need to add a few lines of HTML to your blog.

First, find the help pages for delegation for your OpenID provider. Here they are for MyOpenID, and here they are for MyVidoop.

Now log onto your instance of BlogEngine and go to the settings page. Towards the bottom of the page, there is a text box labelled “HTML Head Section”. Paste the HTML from the help pages into this box, and save.

This is what mine looks like:

<link rel="openid.server" href="" />
<link rel="openid.delegate" href="" />
<link rel="openid2.local_id" href="" />
<link rel="openid2.provider" href="" />
<meta http-equiv="X-XRDS-Location"
content="" />

Of course, these are my details – make sure to put yours in.

And don’t worry, I’m not showing you anything sensitive here. This information is plainly visible to everyone with a simple view source – there are no secrets here.

What this is doing is telling the web site you’re trying to log into that you have delegated your OpenID. You tell it the server it needs to speak to ( and who that server knows you as ( in my case).

3. Let’s log in to something!

The simplest was to test is to go to this checkup page, which will try and log in for you. Enter your blog address, ( in the text field and hit check. If all is well, you should see something like:


This shows that the checkup site, my blog and MyOpenID can all talk together properly.

Now click the “Try logging in” link.

This time, you should get redirected to your OpenID provider. Here, MyOpenID is telling me who is trying to authenticate ( and prompts me for my password (or Information Card – yay for phishing resistant logins!).


Once I’ve successfully authenticated with MyOpenID, I’m redirected back to the test page, where it confirms that everything is working as it should.


And there you have it.

Three simple steps, and now your blog is your OpenID. Go use it to log in to all those sites with the cute little openid-16x16 icons. Go on, shoo.

Tags: , ,

Living with – addendum

by Matt 24. March 2009 18:56

I meant this to a part of the last post, but I forgot. One of the really big things that gets wrong (really wrong) is the lack of any kind of logging, tracing or health monitoring.

This comes as rather a surprise, seeing as there is so much going on in this project – custom HttpHandlers and HttpModules, different data backends (xml or sql), asynchronous processes, etc. The potential for things going wrong is rather large, and there’s no built in way to diagnose the error – or even to know that there was an error.

And no, there isn’t a patch for this one.


Living with

by Matt 23. March 2009 16:46

Last week, I migrated this blog to run on While I haven't posted anything, I have (of course) been tinkering, and here are a couple of things I've noticed:

1. Speed. It's fast. I mean, really fast.

Except when it isn't.

First day after the migration, it was very, very slow. It would take upwards of 30 seconds to display a page. Firebug easily showed the problem, which was a call to retrieve a script from WebResource.axd.

All scripts in are served via an HttpHandler, js.axd. This handler minifies and compresses the files, and sets cache expiry dates. Very useful, at least for any scripts that you add to the page yourself.

Scripts that come from the controls, however, are another kettle of fish. They get served via a different handler, WebResource.axd, which pulls the data from assembly resources. The scripts aren't minified, and they aren't compressed.

So, when the BlogEngine guys wrote the module that compresses responses from the system, they also do a small sleight of hand to redirect any requests for WebResource.axd to go through js.axd. Due to the rather, um, obstinate nature of the WebResource handler, the only way to get this data is by passing the complete url (including domain name) to js.axd, which can then make a web request to go get it.

Unfortunately, and somewhat bizarrely, any request from my server ( to what should be itself ( hang until they timeout. Hence the big pauses.

On the bright side, this interception is configurable (and actually off by default), so it was easy as turning it off in the settings, and we were super-fast again.

2. I made a tweak to only output one feed auto-discovery link. Currently, BlogEngine advertises both the rss and atom version of the feed. From the Windows RSS Platform Publisher's Guide best practices section:

DON'T list the same feed in different formats

Unless you have a really good reason, it's not a good idea to have two links (or three!) that provide the same feed in different formats. It just makes the user have to pick between two things that they are not capable of distinguishing between. Pick your favorite format, and just support that.

So I just advertise a single link using the preferred format (as defined in settings). There's a patch on codeplex (#2635 - direct download) that fixes this for page and comment feeds.

3. There is a small security hole in the implementation of the metaweblog api. Uploading a file does not ensure that the file stays within the App_Data/files folder. This is mitigated by the fact that you can't upload without a username and password, but it could be used to overwrite the users.xml or roles.xml files and allow an editor to become an administrator. OK, not a huge security hole by any means, but it's nice to be fixed. Patch #2636 on codeplex (and direct download)

That patch also urlencodes the identifier used in the url that gets returned, due to point 4...

4. Windows Live Writer uploads files using just an ascii filename. BlogEngine does get enough extra information that it could create a new folder per post (based on post id), but it actually just saves the file using the given filename. Which could cause problems if two posts both use picture.jpg...

Normally, WLW gives a filename that includes a path, guaranteeing unique names for your file uploads. So what's going on?

This happens because WLW recognises out of the box. Check out the BlogProvidersB5.xml file in WindowsLive.Writer.BlogClient.dll resources. It includes this snippet:

<description>A weblog engine on the .Net platform.</description>
<fileUploadNameFormat xpp:if="version gte 12.0.1489.0207">{AsciiFileName}</fileUploadNameFormat>
<fileUploadNameFormat xpp:if="version lt 12.0.1489.0207">{FileName}</fileUploadNameFormat>

Which means that when it downloads the rsd file it matches the “BlogEngine.NET” pattern in the engineName element and applies these settings to the account (which explains the weird backslash you see in the Edit Blog Settings dialog). The pertinent one is fileUploadNameFormat, which gets set to {AsciiFileName}. This is one of a bunch of substitution variables that WLW recognises to build up the filename to send when uploading a file.

Fortunately, this can be overridden in the wlwmanifest.xml file by setting the fileUploadNameFormat element to be empty. This causes WLW to use the default pattern of "{WindowsLiveWriter}/{PostTitle}_{PostRandomizer}/{FileNameWithoutExtension}{FileNameConflictToken:_?}{FileExtension}" which should be fairly deducible. And since we're now saving into folders, and the image and file serving handlers just get passed the path to the file, we really should url encode the path in the returned url.

And yes, there's a patch for the wlwmanifest.xml on codeplex too (#2637 - download link).

It also, in a quick throw away kind of way, specifies the edit url for a post, enabling the "save as draft and edit online" command in WLW. Although, thinking about it, this only supports posts, not pages...

But all in, I'm very pleased. Although I've still got to decide on a theme...

PS. The code formatting extension leaves a bit to be desired, too.

Tags: ,

Shiny new blog

by Matt 10. March 2009 19:46

Ever wiped all the data off a web server and started again? It’s kinda fun, in that cross-your-fingers-and-close-your-eyes kind of way.

I’ve just moved this blog on to, which means I’ve now got to apologise for all those duplicate entries in your feed reader (although if you’ve been reading along in Google Reader, this will be nothing new to you).

Everything seems to have gone smoothly. All the content’s still here, and all existing links, including feed subscriptions should automatically Just Work through the magic of URL rewriting. But if for some reason your feed reader doesn’t update itself, point it to the new feed endpoint –

This has been something that I’ve been meaning to do for ages, but it’s only in the last couple of weeks that I’ve finally pulled all the pieces together to get it working. Turned out to be quite an interesting piece of work, and I think I’ll write a couple of posts about what it takes – migrating content and maintaining links.



Month List


Comment RSS