Code Wizards’ Blog

Its always hard when you inherit code, especially when it’s badly architected and hard to handle.  With ClickOnce we got a whole new bunch of issues
Lately we’ve had a bout of this and a great blog post at Matt Faus’s Old Blog Post on ClickOnce Locations on Disk helped enormously with the location of the cached app files on the C drive.

However, we’ve also been having fun with securing the clickonce application.  Our client had two install locations for the code.  One of the intranet (nicely locked down by group permissions to a website using NT integrated authentication) and the second on a public facing website.

They’d tried to lock it down by creating a local NT user on the web server, then locking the clickonce website down so it required a login with basic authentication.  All this seems sensible but it doesn’t work: the user hits the URL and types in the username password and hey presto there’s the install page - all good.  However when they click install things start to go wrong in different ways.  Some users can’t  even see the download occurring, others go to the setup.exe in the subdirectory and that starts up and fails when it tries to start the app.  Others have even more fun and the install seems to go along until it mysteriously stops, the last group just saw a bunch of xml from the manifest.

The seeing xml issue was easily cured - it’s the MIME type of the served document wasn’t as a clickonce application.  The others were a real pain
A lot of investigation showed that the method doesn’t work at all for securing the content and the alternatives are leave it empty or obfuscate and hide things to stop casual installers.  We reluctantly opted for the latter as we were running out of time and the client desperately needed to get things working.

We continued locking down the main click-once application’s web directory to an NT user - this forces the user to be authenticated to get the application’s install/run page and the manifest.  For the subdirectories we added a random path to each of the installed versions and removed any authentication, then modified the manifest XML accordingly to point to the relevant directory.

Proud of ourselves?  No.  Is the client happy?  Yes.  Is this something we’ll keep in mind for the future?  Hell Yes!  From our experience clickonce apps available from the internet that require securing isn’t a great idea.