LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Multiple Users Login with Multiple permission levels

Good Morning All, 

 

first of all I'm looking for tips rather than instant solution. 

 

i'm building my software that depends on multiple subVIs which i'm going to merge them at later point. 

 

my system contains of the following. 

 

the first Login page. which contains from Tab Control that is having my Logo (picture) and an Enter button, when you press Enter button that takes you to the login details

in the Login details I declared a username as Admin and password (current date ddmmyyyy). 

here's my first question, how can i make my password to be chosen by the user him/her self ?

and how can i declare my keyboard enter key to be active, not only when you press on Login button on the VI. 

I'm saving the username and the password in CSV file, that already declared by me but how i can make it as a database to save every time the changes with details of the time that you logged in.

 

when you successfully login, you'll directed to another subVI ( client details) where you'll be able to add some details such as your ID, your age and some other details. after that you'll be directed to another subVI where you'll have more data that you collected from the user him/her self. 

 

i'm still in my initial stages of the software. but i'd love to have 4 different permission levels to this software from the Login page. 

 

1- Administrator who will be able with his login details to view and edit anything in the whole VI. 

2- Admins/XXX: I want to add several admins that should start with admin/xx and with their own login permission, will be able to add other admins, deleting, viewing the details from other subVIS.

3- User A/XXX: those user should be added by the Admins/xx and with the login permission will be able to edit the updated changes in few details (such as selecting one of the client details and updated it).

4- User B/XXX: those people should be the service team that they can debug the software and have no access more than debugging and updating the system. 

 

I already built the login page with admin (one admin) - from that i'm directed to the client details to add age and ID - after that i'll be in the page that have more details (the one that collected the client details in real time).

 

I'll appreciate any tips, i'm learning a lot from those forums also I just booked my core1 and core2 training in the end of April. 

 

please check the pictures of my front panel 

 

 

Cheers. 

0 Kudos
Message 1 of 10
(5,739 Views)

Hey,

 

You mention databases. Have you used databases before? Do you know which management system (if any) you want to use?

 

How much protection does your collection of access levels need? O mean, a user can edit a csv file outside of labview, for example. Is this is a problem? 

 

You can consider looking into a simple state machine as a starting point but you'll want to consider the possibility a user could wire constants instead of the designed check to elevate themselves if you don't control that. 


GCentral
0 Kudos
Message 2 of 10
(5,708 Views)

Hi,

 

You mention databases. Have you used databases before? Do you know which management system (if any) you want to use?

 

I used both Access and My Oracle before, I don't have any access to any of them now, but i can install them easily. I do have a license for Microsoft Access.

 

How much protection does your collection of access levels need? O mean, a user can edit a csv file outside of labview, for example. Is this is a problem? 

 

should be very protective. No access out of the LabVIEW. everything should be done within the software itself.

 

 You can consider looking into a simple state machine as a starting point

 

I have a good theoretically idea about simple state machine, and i used to solve problems on papers for this topic. never knew it through labview.

 

want to consider the possibility a user could wire constants instead of the designed check to elevate themselves if you don't control that. 

 

can you clarify please ?

 

 

thanks for your reply.

0 Kudos
Message 3 of 10
(5,702 Views)

@N.Ghrayeb wrote:

 

should be very protective. No access out of the LabVIEW. everything should be done within the software itself.

 

 You can consider looking into a simple state machine as a starting point

 

I have a good theoretically idea about simple state machine, and i used to solve problems on papers for this topic. never knew it through labview.

 

want to consider the possibility a user could wire constants instead of the designed check to elevate themselves if you don't control that. 

 

can you clarify please ?


Regarding the last point, what I meant is if you imagine a simple solution as having either a) some buttons, which when you click, check the value of an enum on a shift register with values like 'admin', 'user-A', 'user-B' and then either take an action or tell the user it is disallowed, or b) you hide buttons that aren't allowed for a user based on the same shift register and enum, then you'd want to take care that someone couldn't open the Block Diagram, and remove the subVI or subVIs that changed the value on the shift register for constant values, such as 'admin', when they did not have the password and so on.

 

This ties in with your comments on being very protective - I'm not sure what the best way to prevent users from accessing whatever you store your access rights in (for example, the database file). It might be that you could have only a 'LabVIEW' user with access to the database, using the database's access management system (I'm suggesting this because I don't know how to securely control LabVIEW - someone else might have a simpler/better solution) and then have the VI that opens the database connection and 'logs in' to the database lock the block diagram with a password you don't give to (any) users. 

 

Then, you could just check two strings in the database using this 'secure' connection. Be aware, that it probably isn't actually secure. Something like 'SELECT AccessLevel_ID WHERE UserName = <name> and Password = <password>' seems likely to be attackable from all sorts of directions, and I don't know enough to tell you what to watch out for!

 

From a LabVIEW point of view, you're wanting to ensure that other users aren't able to just completely bypass your system by giving a false value to things that check it. Hiding the value inside class private data might help with this (since you could leave the data member with no public accessors, and only private access via the authenticated database connection) but I imagine it isn't too hard to take a LabVIEW object, flatten it to string/xml/variant, and then change an integer value or similar. I'm not sure what the most secure way is. If you need something that with withstand more than simple attacks, you'll need to either be or consult with someone knowledgeable about security protocols and proceedures.


GCentral
0 Kudos
Message 4 of 10
(5,654 Views)

hey there,

 

thanks for your reply, I'm going to take everything you mentioned into consideration and give it a go. I'll try to use the Enum procedure to make the user choose between the levels. but I was trying this before few minutes. 

I didn't know how actually I can design it similar to a login details such as (Admin/ xx) - I didn't know how to program it.

what I have now in my block diagram, a System String name comparing with fixed block "admin", if it's equal then will give you an access otherwise wont. 

 

I know my steps are not the best, but at the end I know that i'll have a good strong VI, when i finish everything in my mind. 

please have a look to what I've done

 

 

Thanks again

0 Kudos
Message 5 of 10
(5,648 Views)

To be clear, I don't think you should allow any access or choosing of the enum value by the user - this should be something your code decides based on the username, probably.

 

This was what I thought you had in mind:

db-levels.pngThis is a completely non-functional VI that just defines an icon and access pane for illustrative purposes. You'd probably also want to consider an input for either a class wire, or a database connection - but be aware that if the database wire is visible on a block diagram, you could add more subVIs to create additional calls into the database (like 'UPDATE Users SET AccessGroup_ID = <admin, top level, etc> WHERE User = <me>' or similar)


GCentral
0 Kudos
Message 6 of 10
(5,625 Views)

Hi, 

 

thanks for the good advice, I haven't had time yesterday to work on this project, but i'll try to process now. 

 

I'll consider all your tips and i'll keep posting my updates and problems. 

 

 

 

 

Regards,

0 Kudos
Message 7 of 10
(5,601 Views)

Hello  cbutche

 

I started building each SubVI individually and I started with the Admin page, then i'll go back to give the permission to everyone as it's easier for me to break down every page alone. 

 

however, through what i'm planning to do, the admin should be able to add, remove and View (history, stations/subVIs, and many details).

 

I found 2 problems till now. 

 

when i'm adding the new details/elements to my table. the old ones will be removed automatically. so how can i keep them saved. 

 

however, after the first iteration or running, the VI stopped then i need to play it again and it'll run normally 😕

 

second, my stop button won't work, i guess i made a mistake somewhere. 

 

please check my pictures.

Download All
0 Kudos
Message 8 of 10
(5,589 Views)

Hey,

 

So it seems like I missed an update here, and it's been some time - sorry!

How is the project going?

 


GCentral
0 Kudos
Message 9 of 10
(5,496 Views)

Hello mate, 

 

sorry i was away for the last week or so. 

 

I changed the plan to be one permission, but with trace-ability to the user himself. 

 

now I'm working on this idea through tab container, using local variable to specify the user to enter his username and password in case he want to jump from tab to tab.

 

but i'm still in the process to enhance my VI as much as i can

 

 

 

Cheers mate.

0 Kudos
Message 10 of 10
(5,462 Views)