Jump to content

Users are inherently DANGEROUS !


crelf

Recommended Posts

on the one hand, this a good idea, on the other hand, it is not, because, you add some extra difficulties to your development:

during development, it's easier to open an *.ini file with the notepad and edit some entries, than open regedit and edit data stored in the registry.

if your software is in production, it is easier to request someone, "plz send me the *ini-file, I need to see your settings" than to request an export from the registry.

maybe a combination of *.ini file and registry would be a good solution: when closing the programm, make a MD5 hash and store that hash in the registry. Then you can detect any changes and display a "corrupt file" message !?

cheers,

CB

I thought about using the registry but i really dont want to get into that whole mess... i am going to try the checksum for now and TRY to force the burden back onto them.... maybe , just maybe , they will learn if they get burned a few times...

luckily these guys dont fit into this category "Nothing is fool-proof for a clever fool." , but , i wish they would jsut stick to letting the program do what it is desinged to do , everything that needs to be done can be done from within the program i wrote....

oh well i guess it could be worse.............

Link to comment
i had a long talk to the techs about modifying these files etc.... and explained to them that it messes things up when these files are played around with , and , guess what , you got it , they still messed around with them...

heh heh heh :D Sorry Dan - I don't mean to laugh, but it's an issue that I'm sure all of us have been through at least once. I feel for ya mate - keep your chin up!

Link to comment
heh heh heh :D Sorry Dan - I don't mean to laugh, but it's an issue that I'm sure all of us have been through at least once. I feel for ya mate - keep your chin up!

Chris

yeah i know , it just seems to be getting worse , i try to make my programs as flexible as possible so i dont have to keep editing etc... but it also tends to come back and bite me i the A** at times :angry:

ah well jus a couple more hours then it's :beer: time.... i think it may be a Guinness night after the past couple of days.

Dan

Link to comment
ARRRRRRGHHHHHHHHHHHHHH.....

i had a long talk to the techs about modifying these files etc.... and explained to them that it messes things up when these files are played around with , and , guess what , you got it , they still messed around with them...

I don't believe that the solution to your problems can be resolved with software...It looks more like a "dispcipline/responsability/maturity" issue that can only be resolved by a supervisor, or the supervisor's supervisor, or the supervisor's supervisor's supervisor...and if this does not fix the problem, then :throwpc:

Link to comment
I don't believe that the solution to your problems can be resolved with software...It looks more like a "dispcipline/responsability/maturity" issue that can only be resolved by a supervisor, or the supervisor's supervisor, or the supervisor's supervisor's supervisor...and if this does not fix the problem, then :throwpc:

i dont want top resort to that , but , i may have no choice...

Link to comment
ARRRRRRGHHHHHHHHHHHHHH.....

i had a long talk to the techs about modifying these files etc.... and explained to them that it messes things up when these files are played around with , and , guess what , you got it , they still messed around with them... rather than go through all the hassles of changing everything over to hidden and encrypted files i have decided to play games with the techs and put the burden back on them...

I think you can solve this issue by creating a LV exe that is run as a NT-service.

The only thing this exe would do is to open the file/files and keep them opened.

This will prevent any user from editing or deleting your files, but they can still be read.

/J

Link to comment
  • 2 months later...
It seems to me that some sort of "encryption" will be necessary. :(

I haven't used the technique, but there was a section (6.3) in "A Software Engineering Approach to LabVIEW" that discussed this EXACT problem, and presented a solution. You can download the examples from the book HERE. You would be interested in the CONFIG INI code.

The idea is to replace the Config Data Read & Write vis in the Open Config Data and Close Config Data vis with the encrypted versions (downloaded from above).

Maybe you could leave the NI libs alone and create a private version of the Open Config Data and Close Config Data vis. You could use case statements that key off of the Application:Kind property to select between using the unencrypted NI Open and Close INI vis during development and the encrypted when called from the runtime engine...

I think a somewhat smarter way for ini files (and XML files are just as simple) would be to add an extra key such as SecurityHash=AB123FE45...

Calculate that hash using all the key names and values of that section in a deterministic way combined with a hardcoded private key and a hash function such as MD5 or maybe better SHA-1. On load read that key and verify it. If failed use default data instead. After having had to enter a complete configuration two times most users will probably stop altering files (or be so pissed off that they won't use your application anymore ;-)

Rolf Kalbermatter

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.