The MTPS Content Service - A SOAP Success Story

When I wrote the MTPS Content Service (was that a year ago already?) I didn't really expect people to use it much. I figured there'd be a few small and interesting apps - for instance, I wrote msdnman mostly for fun - but that it would largely be a useful but little-used service.

 

I was quite wrong.

 

The other day I found out the usage numbers for the service. The conversation went something like this:

 

Kim: "Hey, I wanted to tell you the stats are in for the content service."

Me: "Oh really? I'm curious - what are they like."

Kim: "Here, I'll email you the numbers."

Me: "Wow! It's only been a year and there's been 1.3 million hits - that's a lot!"

Kim: "No, that was for yesterday."

Me: "…"

 

I was quite literally speechless. Which, if you know me, you know is a rare thing. :) That's fifteen requests per second, so perhaps I can be forgiven my momentary surprise. (Traffic has since subsided to a mere 600K requests or so per day - an average of around seven requests per second.)

 

I have to say I'm fairly proud of having written a web service that can sustain those sorts of loads. Of course, the credit is not due all nor even (close to) mostly to me: the service is a fairly thin wrapper around the MTPS system, and I was only one part of the team that did that. Plus, without a crack ops team it doesn't matter how good your software is - you're not scaling. Kudos to those guys as well. All I had to do was not screw up the translation to SOAP. :)

 

We don't really have good data on what applications are creating all this traffic. We do know that the recently-released PackageThis is responsible for somewhere around a third of the traffic. We know that because PackageThis is the only app currently sending an AppID header with their requests. An AppID header is just a short string that identifies the application making the request. This is something we added rather late in the development cycle, never really documented, and made optional. So maybe it isn't surprising that it's not showing up in a lot of the requests. Hopefully we can fix that at some point.

 

Sandcastle also uses the service, and I wouldn't be too surprised if it accounts for the bulk of the remainder of the traffic. They're adding an AppID header soon, so we'll have better data then. It certainly will be interesting to see - personally I'd love it if there were still a whole bunch of unknown apps in the traffic pattern, as it would suggest that lots of people have found good ways to use the service. Which was our hope when we wrote it.

FlexWiki 2.0 Security Bug Alert

I noticed something weird on one of the wikis I’ve upgraded to FlexWiki 2.0. Even though I’d locked down a namespace to only allow authenticated users to edit, I was still seeing new topics getting created. Sure enough, when I tried it myself, I was able to create a new topic even though I wasn’t logged in. Fortunately, the problem only seems to manifest with new topics: editing of existing pages is still correctly prevented by the security provider.

 

After a bit of digging, I figured out that the problem is with the way permissions are handled for nonexistent topics. Basically, users were granted full control over nonexistent topics. The correct behavior is for nonexistent topics to be given the default permissions for the namespace, as once they are created, that’s what they’ll have (absent explicit permission statements). I’ve coded the fix and submitted it – it’s present in build 2.0.0.49 and forward.

 

Note that the fix makes the wiki secure by ensuring that unauthorized writes can't happen, but that the UI is still somewhat wanting: You're not told that the write is going to fail beforehand. I'll make that change soon. I just wanted to get a patch out to solve the underlying problem as quickly as possible.

 

If you’ve deployed FlexWiki 2.0 you should seriously consider upgrading to this latest build. Available here.