LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How to create a permanent setting

I have developed my LabVIEW applications every now and then and most of my application settings are read from setting file stored in TEXT file format(*.txt).

This method of storing my application setting pose problem when somebody tried to open the file and modified the setting file. Consequently my application will encounter problem during execution.

In the end, I implemented the checksum on the setting file but this still could not prevent other users from accessing my setting files.

In other words, what other methods that I can use in order to store my application's permanent settings from other user? Hiding the files could be the solution but user could still unhide the files. I have thought of accessing the registry of oper
ating systems and store the settings inside the registry but how can this be done or is there other ways to do it?
0 Kudos
Message 1 of 4
(2,773 Views)
Instead of stumbling over any little error in the configuration file, you should probably use the tools from the "Configuration File VIs" (in the file I/O palette), it make this a bit more robust.

For example, if a key is suddenly missing, you'll get the default value for the key as defined.

(Of course you could also use some kind of encryption that would make any manual editing impossible.)
0 Kudos
Message 2 of 4
(2,773 Views)
Hi,
You can keep track of the date the config file has been modified ,so that if at all it is changed ,you can re write it with a default file which you store in your program,else there is no other way that you can deny the user from accessing it as WINDOWS it self does not give any security for it files himself.Else You will have to encrypt it .
0 Kudos
Message 3 of 4
(2,773 Views)
KF;

First, if possible I'll follow altenbach suggestion. The Configuration File VIs provides you with part of the functionality you need if a key value is missing.

Wihout knowing the purpose of your application is difficult to suggest the right approach. I hope the following guidance can give you a start:

If nobody should know the settings, you should encrypt it.

If there is no problem with people reading the settings, all you want is that nobody can modify them, you need integrity check, which is the checksum you are doing.

If there is no problem with people reading the settings, but for some reasons (here is where understanding your application is important) just an integrity check is not enough, you need to sign it.

If modification of the set
tings has serious consequences (again, understanding your application is important), you need to incorporate robust error handling.

The right mechanisms depends on your application.

Regards;
Enrique Vargas
www.visecurity.com
www.vartortech.com
0 Kudos
Message 4 of 4
(2,773 Views)