Kumar Devvrat

I am not really sure how many organizations use ClickOnce to deploy their application from publicly accessible URL and am really skeptical about it. However, it’s a wonderful deployment technology and still can used by with some level of security on public URLs.

I am presenting an overview of how to setup basic authentication and security with WAMP stack. This is imported from my answer to this StackOverflow question. If you like it, please upvote it there.

Public URL is a security issue in ClickOnce Deployment. However, there is a solution for your problem if your web server has windows and .NET installed. Tell me if you have one ? I will have to come up with another workaround for Linux web server in case you have that.

Brief

Firstly, a bit of information about ClickOnce deployment. When you deploy the application, the GET requests on the server made are (assuming WebDir is the publish directory on the server)
G-1. GET /WebDir/setup.exe (Initial download)
G-2. GET /WebDir/MyApp.Application (setup.exe -url request)
G-3. GET /WebDir/MyApp.Application (.application deployment provider URL request)
G-4. GET /WebDir/Application Files/MyApp_1_0_0_0/MyApp.exe.manifest (Application manifest request)
G-5. GET /WebDir/Application Files/MyApp_1_0_0_0/MyApp.exe.deploy
and other .deploy files … (Application file requests)

Implementation

Now, the solution is to intercept these file requests on the server. On IIS, you can attach a custom HTTPHandler and handle the request. On Apache, you can redirect requests to a PHP code using .htaccess files. Apart from this, you will have to generate unique identifier uid for client instances downloaded from the server (can be your license key) and put that in the deployment provider URL query parameters.

Directory Structure

Create an "Application" folder inside your WebDir and restrict access to/WebDir/Application/. Rest everything can be there inside /WebDir/

File Requests

So here’s what you do on a Apache web server hosted on a windows machine:

1. Create a custom download page or use the one created from publishing the application using Visual Studio (but you will have to edit it manually!). Let’s assume that page is /WebDir/Download.php
2. After authenticating user from Download.php, you have to send setup.exe from your code (can do it with readfile() in PHP) to the user. However, the catch is bootstrapper (setup.exe) after installing will do a GET request [G-2]. Don’t forget now, that you have to validate this file request. So basically you change the "setup.exe -url" property to include uid before returning the file. For eg: change it to /WebDir/uid/MyApp.Application [G-2]. You can use MsiStuff.exe to change the URL property for the bootstrapper.
3. Using a .htaccess file, rewrite [G-2] to /WebDir/Handler.php?user=uid. From Handler.php, you can check if it is a valid uid. If it is valid, you will have to include the uid in the deployment provider URL and “Dependent Assemblies Path” in deployment manifest so that if an upgrade request comes (It essentially requests the deployment manifest), you can validate the user there too. Add uid to query string parameters. For eg: change it to /WebDir/MyApp.application?user=uid [G-3]. Don’t forget that you will have to resign the manifests once you modify them. Use Mage or write your own code to do that.

So finally, the GET requests on the server will be (assuming uid=1f3rd)
G-1. GET /WebDir/Download.php
Action: return setup.exe with the -url changed
G-2. GET /WebDir/Application/setup.exe/1f3rd/MyApp.Application
Action: redirect, validate user, change URL, re-sign and return file
G-3. GET /WebDir/Application/setup.exe/MyApp.Application?user=1f3rd
Action: redirect, validate user and return file
G-4. GET /WebDir/Application/1f3rd/Application Files/MyApp_1_0_0_0/MyApp.exe.manifest
Action: redirect, validate user and return file
G-5. GET /WebDir/Application/1f3rd/Application Files/MyApp_1_0_0_0/MyApp.exe.deploy
and other .deploy files …
Action: redirect, validate user and return file

Pros

1. Application is successfully deployed and upgraded only if all the requests have a valid uid in the URL present.
2. You can now identify different instances of application on client systems. You can track the update history, do a selective version upgrade/downgrade and much more !

Cons

1. You will need a windows server to implement the above since you need mage.exe | your-own-.NET-code-signing-application and Msistuff.exe.
2. You may have minor performance issues since you are performing validation on every file request. You can choose to skip validation on .manifest and .deploy file requests.
3. You will have to ensure proper security for companies certificate which will be present on the web server for signing (You can store it on the server local file-system if you have the full server to yourself. In that case, it is fine unless somebody breaks into machine itself !)

Additional resources on the same
1. Administering ClickOnce Deployments
2. ClickOnce Licensing HTTPHandler