Hi,
a ProBono ‘client’ asked for a Password feature to restrict the usage of the software to some persons only.
Any clue to implement that is welcome. TIA
It might be a help is you gave us some kind of idea of what the application does and where it runs (desktop, internet…)
That question is very generic. You could do 2 versions. Or you could do a full blown rights management. How are people identified? Do they already have to log in? How much do you want to segregate your users?
Thank you for your answers.
I am sorry for the lack of informations. Here’s more data:
-
Desktop application (single user / computer db front end).
-
Window design:
I have a splash screen who display some information from the data base.
I want to add the Password process there.
I think at a TextField with an OK PushButton (and a Quit PushButton)
The “user” type one Password, then OK and the application quit (wrong password) or close the splash screen and opens the main window to let the identified (by the Password) user.
Ideas ?
Well… Either you want different passwords for this application or the same password for every user.
You can put the password inside the code.
I think you described the answer quite good in the last post!
Of-course, you could always keep users and passwords in a database on a web server and ask for them at each app.open but for your case it might be little too much work for this particular case.
Code: (on the “OK” button / action.)
IF fieldPassword.text = “123qwerty” THEN
window2.open
ELSE
quit
END IF
No. Don’t do that. Save a salted hash of the password, not the password itself.
And I assume the database is encrypted, or can anybody just open it with a different app?
I think the thread creator (Emelie) must decide how critical this application is, what kind of security that is relevant.
I’m a true believer of slappy security when the situation calls for it…!
It may not be the correct way to do things, but who cares!? As long as it works, then all is fine, everybody’s happy!!
I second Markus’ comment. Clear passwords should never be kept in a database. Hardcoded passwords in an application are in my opinion even worse.
That said, if your application is using a central database that users cannot access (only the special user defined in the app can access, in addition to the db admins), then you could create a table with user and password information, and check against the table when the password is entered. I do not mean to actually keep the password in the database, but a hash code. The hash code is not generated only on the basis of the password. The minimum starting point should be the concatenation of the username and password.
This security concept is used by some of the leading ERP systems. Individual users are not granted db access, the app is granted access. Users are managed within the app.
One of my apps uses such a security system. It relies on several tables in a full blown authorizations system that lets the manager handle user-specific rights to the various transactions. I have an administrator method that generates the initial hash for new users. The same algorithm is used in the logon procedure to generate the hash code, which is then compared to the hash code in the database. Users can change their passwords. The same algorithm is used there also.
A simple implementation of the concept can be designed and coded quite easily.
my 2 cents. I hope that this can be useful.
Hi all,
there is no need to secure the password because the users are nearly newbies (this is for a Charity institute). All they want is just avoid anyone to go onto the software. They have pdf versions of the db contents to check.
Only one or two people are able to use the software (to avoid misnamed persons, country names, etc.
The problem withmy current implementation lies with MenuItems are available and displays some application window frontmost (then in the background depending of the Window kind).
I am not able to avoid those keyboard shortcuts to stop working in the splash screen window (I do not set any MenuBar to that window).
To use the software as is now: you only need to know the keyboard shortcuts or try some.
This is in oth Windows XP and OS X 10.8.5
Any ideas ?
BTW: Happy New Year !
Nope they should not. No matter how “simple” the apps use is.
There is a risk that the user uses the exact same password elsewhere so leaving it in clear text is a bad idea 
Remember: security password is failing when one person gives his password.
But this is not the question. Please.
Make the splash screen a movable modal window, then enable it’s EnableMenuItems event and use it to cycle through all the menus and disable them except for Edit->Cut, Copy, Paste, Select All (etc.).
Even better, in your App’s EnableMenuItems, check to see if the frontmost window is a modal or movable modal and only enable the menu items you want accordingly.
I haven’t tried this last suggestion, but create a second, minimal menubar and assign it to the modal dialog.
FWIW, I agree with others that you should not be storing the plain password. Even if it’s a single password that will be hard-coded, it’s just as easy to store its hash instead.
I do not enable any MenuItem / I have not set a MenuBar to that window.
I will try “In App.EnableMenuItems: check to see if the frontmost window” is my password window
I also will check in a brand new project if that behavior exists following my project conditions.
I think this is a bit strange and I feel a bit stupid to not have an idea to work (around) with that.
On the topic of the password window, I once created a splash screen/about box that would double as a logon screen in an old VB6 app. I stopped doing multi-use screens like that since. Here is how I managed the logon elements:
1- There was a global boolean variable (an app property?) to determine whether the user was already logged in.
2- Wherever there were elements to display/activate, or globally available functions that were dependent upon the login status, I would check against the global variable. If logged in, then I would proceed with the appropriate code branch or otherwise exit without any action.
3- The login procedure would set the variable upon success. Checking for the parameter was done with a global function (a method in a module?) If the method returned a specific value, say True, then the user was logged in and activation, display or procedures would be fired appropriately.
For example, the code triggered by your problematic shortcuts could first call the method, and exit before doing anything if the user is not yet logged on. Idem for the code that manages the menubar.
Hope this helps. Happy New Year!
Thanks
Happy New Year too
Hi,
I just checked with a brand new project with two windows. There is no menu bar is attached in the second window (default feature), but I set it as Window Frontmost.
I added a MenuHandler in the App Class, run and as amazed as I was, the keyboard shortcut displays the second window. And the front window does not have menu bar attached.
I remember clearly that I was crying (many times, in more than one different project) when I forgot to attach a menu bar to the window I was debugging.
Nota: I do not recall what I was doing at that moment.
So, I was under the impression that if no menu bar is attached, no Keyboard shortcuts is able to fire / to be fired.
Id better go to eat something, watch a movie on TV and when my brain comes to 36.5° Celcius, resume to bypass this trouble (for me).
I do not know if I follow Louis advice or if my brain comes to a solution one hour after reading his answer.
Anywhay: thank you Louis.
I added a Boolean Property that I set to False on Window Open.
If the password is OK, I set it to False, else to True and issue a user report before quit (MsgBox). Yes, drastic.
In App.EnableMenuItems, I check that Boolean value and if True, I disable the MenuItems
*
Works fine in a testing project (one window, 1 PasswordField, two PushButtons [OK / Quit].
- But I do not like that: why must I have an If / Else / End If block to always be fired when the application is used. Something, somewhere is wrong.
Ideas are not necessarily meant to be followed religiously. I see them more as seeds for my own solutions. I am just glad that the proposed inspiration led you to implement your own solution.
… can’t explain. Sometimes, I find it easier to just walk around a problem than to try to get to the bottom of it and I find that kind of lazyness to be more productive than being on the purist side. Other times, I just “need” to get to the bottom of it. Depends on the schedule, I guess.
[quote=56218:@Emile Schwarz]Works fine in a testing project (one window, 1 PasswordField, two PushButtons [OK / Quit].
- But I do not like that: why must I have an If / Else / End If block to always be fired when the application is used. Something, somewhere is wrong.[/quote]
If it works, dont fix it 
Remember there is a menu handler hierarchy: Control - Window - App. If you put a menu handler in App, it is always active (that’s why you would put it there, because you want it to always be the same regardless of which window is active). In this case, you have 2 options: Use a boolean like you have, or Move the menu handler out of App.