User management in LabVIEW applications

[GregPayne]

Hi CSLUGgers,

Hope you all are doing OK and surviving being locked down (or up)?

I'm slowly working my way through a backlog of nice-to-have features and going to start working on a user login/management module. 

I'm sure these already exist in many forms so before reinventing one I thought I'd check if anyone has something they'd like to share.

Cheers, 

Greg

[swatts]

I've done a few, but the best thing I can do at the start is asking some questions.

1) What problems are you trying to solve by managing users (trace-ability is fundamentally different to security, so it's worth thinking about these up-front)

2) If it's security, have got different functionality for secure and non-secure logins? (if so has the UI been designed to separate those functions easily.)

Also sometimes offering a unique dataset per user is adequate, it is a nice way to manage it (I do this at the Uni, each login generates it's own SQLite dataset, only the area manager has the capability to generate new logins). That way you are not farting around with different screens for different levels and it makes the software design much simpler.

[James_McN]

If you look on bitbucket composed systems have one on there but I've never worked with it. (Found it while trying to play with GPM)

[GregPayne]

Thanks Steve, good points to think about. 

Looking for somethings pretty basic. I already have users in a database so wanted to assign password and a role type. The application would then enable/disable features based on the logged in user. 

Some of my applications have the ability to do this already, there is a 'magic' sequence of keys that are listened for to unlock certain features. It works well, but think making something ties into a user will be better. 

[GregPayne]

Thanks James, will take a look

[James_McN]

I also do have a pure G implementaton of scrypt somewhere for storing hashed and salted passwords. Let me know if you go your own route and I can share it.

(Although I'm now of the opinion that to be as secure as possible this should probably be offloaded to C or the OS, but where security requirements aren't high this isn't an issue)

[GregPayne]

Thanks James, I'll keep that in mind. 

My initial thought is to store them in our database along with the user names. I'm not too concerned about security so a simple hashed password will be OK. I mainly want to enable/disable features within the application and track who is testing what.