restrict access as per log in

[rk_t]

Hello!

I have written a code that compares my username and password as per a file stored in my computer.

I want to apply are 3 basic levels of access to features to my program.

1. Manager: He will be able to add/edit set values and target for day and all other features of supervisor and operator.

2. Supervisor: He will be able to add/edit set values and target for day and all other features of operator.

3. Operator: Just start/Stop and exit.

Now I usually use enum/case structure and while loop to make my state machine configuration. But I am not sure how should i implement the above level in my code.

Any ideas?

Thanks

[Sam_Sharp]

My thoughts:

Create an enum for the user levels (Not Logged In, Operator, Supervisor, Manager) and create/have a file (how secure does this need to be?! best not to store passwords in plain text but maybe you want to encrypt/protect the file as well from being tampered with) that contains the users/levels.

Check details against file when someone logs in and hold the details in your application (e.g. FGV, shift register). You can then disable/grey-out controls on the front panel by checking the access level with a simple equality comparison (e.g. if >not logged in then is at least an operator, if >operator then is at least a supervisor etc.).

You could also have checks inside the state machine just to be doubly sure.

[Bob_Schor]

If you have code that can detect 

---

@rk_t wrote:

Hello!

I have written a code that compares my username and password as per a file stored in my computer.

I want to apply are 3 basic levels of access to features to my program.

1. Manager: He will be able to add/edit set values and target for day and all other features of supervisor and operator.

2. Supervisor: He will be able to add/edit set values and target for day and all other features of operator.

3. Operator: Just start/Stop and exit.

Now I usually use enum/case structure and while loop to make my state machine configuration. But I am not sure how should i implement the above level in my code.

Any ideas?

Thanks

---

It seems to me that if you have code that can determine who is logged on, you could have this code associate (some) users with Manager/Supervisor/Operator roles.  Once you have this, you should be able to "guard" your various controls and options with a "Role" input that does or does not permit a particular operation depending on the Role that you establish at the beginning of your program by calling your "Role" routine (you only need to call it once, and save the Role in a Shift Register or VIG)..

BS

[Hooovahh]

In my opinion storing user credentials is a last resort and other tools should be used for security reasons.  I realize it is just easy to do it yourself but how are you handling things like password restrictions?  Number of characters?  Upper and lower case?  What about how are you handling expiring passwords every 6 months or whatever?  

A better solution is to rely on Windows to handle all of this.  You can query the logged in Windows user, and their credentials and then based on that information you can enable or disable parts of your application.  This can be done using the command line "net user".  Then rules like password expiring, and storing can be done on the local machine, or even controlled by the IT department via domain controls.

If you don't want to use Windows level credentials there is the DSC toolkit by NI which has similar features.  It isn't as standard as Windows for credentials but again you don't need to worry about password entering, or storing.

If you are using TestStand I'd say that is the 3rd option, because it has user login functionality.

If these 3 options really cannot work for you, then I'd say to write something custom, but to be very mindful about how you are storing credentials, and how users are managed.  The amount of effort it takes to do something custom, and done right, is non-trivial which is why I highly recommend on of the other options first.

In any of these options the easiest method to restrict the user is to disable controls on the UI.  Or with an enum you can disable items within that enum so it can't be selected.

[Sam_Sharp]

I think VI Server does also have a built-in domain/account manager (although maybe it's part of the DSC thing)...if you go to Tools -> Security there are options there to configure it and you can query the information using VI Server methods/properties.

[Hooovahh]

I always thought that was part of DSC but looking at the help in the login window it states it requires the Base Package (Windows) so maybe it isn't.