Allow to disable Username and Password save

[tct]

This is a simple decision which, I believe, ought to be down to the user.

[Selva Nair]

In 2.4.1 there is a registry key to do this:
HKLM\Software\OpenVPN\disable_save_passwords = 0 or 1 (DWORD)
The installer sets it to 0. Change to 1 to disable the feature.

[tct]

Which does not disable saving of Username.

[Selva Nair]

Replying to tincantech:

Which does not disable saving of Username.

True.

In the up script for the config ($config_up.bat) do
reg delete HKCU\Software\OpenVPN-GUI\configs\$config /f
(replace $config by the name of the config file excluding the .ovpn extension)

[tct]

Or change the source code as per this Feature request

If it bothers enough people then it may be changed ..
If it does not bother many people then it probably will not.

However, this is the place to for people to go for such a request.

[mderouss]

Concur. What I object to is that OpenVPN ( or at least, it's GUI ) is storing a part of my credentials for a secure service in plaintext. I don't imagine most people are desperately worried about this, but for those that do care, the option not to do so should be there.

[Selva Nair]

See GUI PR-218 ​https://github.com/OpenVPN/openvpn-gui/pull/218

[tct]

See GUI PR-218

I also did not understand the logic until cron2 asked you the direct question.

I feel like you are trying to resist this feature but I don't understand why ?

Your initial design was:

User choice: save username	User choice: save password
Force Yes (Objectionable)	Choose Y/N ?

And your second attempt is:

User choice: save username	User choice: save password
Only on condition that password save is enabled	Choose Y/N ?

The logical and sensible choice of hierarchy is:

User choice: save username	User choice: save password
Choose No	Force No
Choose Yes	Choose Y/N ?

Is that not more reasonable ?

[Selva Nair]

Nice tables.

Is that not more reasonable ?

Yes it is. But its also a little more work :) When did laziness stopped being a virtue?

So how to fix this?

Add another checkbox to the user/pass dialog: make space for it, reposition lines below it, copy the change to all language files (check each for positioning and clipping), add code to keep track of its state in the dialog proc.

Add a flag to indicate username-is-saved or not: check it when creating the dialog and keep it in sync with the checkbox

Decide whether to clear the username when password is cleared using the "clear saved passwords menu" -- or add another menu item for clear saved username. Or don't be that considerate and allow the user to delete a saved username only when the user/pass dialog comes up..

Decide whether to tentatively forget the username on an auth failure or only password need be forgotten.

Ensure the logic is right and doesn't break anything.. Build, copy to Windows, test, re-read the patch, issue a PR and wait for no comments, no review, no user feedback and finally a lazy ACK :)

I'm not resisting: saving username by default was my poor decision to start with. But changing things is never easy. I'll fix it one day unless someone more motivated than me beats me to it.

[tct]

Yes it is. But its also a little more work :) When did laziness stopped being a virtue?

Ahh .. now we see the nugget of truth ;)

I never meant to challenge your values, my goal was simply to get to the bottom this. I think we agree on what is preferred but there are some other factors involved. That is ok by me ;)

Thanks for acknowledging.

[patd@…]

Another consideration would be to disable the 5 second auto-reconnect feature on the client when the Save Password box is checked. With that feature enabled, pushing the "reneg-sec" option is basically canceled out.

[rakuzuhol]

<spam>