I have a link on my website to the standard publish page generated by Visual Studio. My concern is that if anybody finds out the URL to that page, they can download my software. Sure, I could password protect the page with the link, but it still would not be protect开发者_如何学Going the download URL. Are there any ways to secure the click once upload? I have looked around, and it seems like I am stuck in this sense.
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:
- 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
- After authenticating user from
Download.php
, you have to sendsetup.exe
from your code (can do it withreadfile()
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 includeuid
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. - Using a
.htaccess
file, rewrite [G-2] to/WebDir/Handler.php?user=uid
. FromHandler.php
, you can check if it is a validuid
. If it is valid, you will have to include theuid
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. Adduid
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
- Application is successfully deployed and upgraded only if all the requests have a valid
uid
in the URL present. - 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
- You will need a windows server to implement the above since you need mage.exe | your-own-.NET-code-signing-application and Msistuff.exe.
- 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.
- 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 !)
If you want me to make something clear or explain in detail, feel free to ask. In case you have suggestions for modification to the above, post that too.
I will write a detailed CodeProject article if I have spare time someday.
精彩评论