View Single Post
Old 05-12-2009, 11:10 AM
kinook kinook is online now
Join Date: 03-06-2001
Location: Colorado
Posts: 5,758
Based on this post:
I believe what you're looking for is a way to allow users to build a project but edit it only if a password is provided.

As mentioned, the simplest option (already available) would be to install and use only the console application (or VBP runtime) on machines where users should be able to build but not edit project files. Of course, users could circumvent this by installing the VBP GUI application.

One option for us to implement this in the GUI app would be to simply store a password (in encrypted form) in the .bld file and if found when loading, disable editing unless the password is provided. However, a knowledgeable user could simply remove the password from the project file (or modify other properties in the project file itself) before opening it. This would be easy to implement but also easy to circumvent.

A more secure method would be to save files that require a password to edit in an encrypted binary format or with an XML digital signature (to prevent tampering). This would be more secure (and take longer to implement), but keep in mind that since the file would need to be encrypted with a key hard-coded into Visual Build (so that it could always be unencrypted in order to build), it still would not provide much protection -- an enterprising user could determine the hard-coded encryption key without too much effort (and once available, it could be used by anyone who obtains it) and edit protected project files.

The highest level of protection (which also is already available) would be to prevent users that should only be able to build projects from having direct access to .bld files, for instance by providing them with a web front-end for launching builds on a machine that they can only access via http (see the WebLauncher sample), or via remote execution of builds.

So I'm wondering what level of edit protection you expect or require.

Reply With Quote