openvpn-gui
openvpn-gui copied to clipboard
OpenVPN
On Windows, follow Windows patterns/practices.
Configuration data for installed applications on Windows should NOT go in %USERPROFILE%. It should instead go into %APPDATA%/<vendor>. At the moment on Windows, OpenVPN installs its configuration into %USERPROFILE%/OpenVPN/. This folder is meant to only store files intentionally saved here by the user (e.g., via a save dialog box). Applications should not be writing arbitrary files to this location.
Please follow Windows best practices and move the config location to %APPDATA%/OpenVPN/.
I fully agree with you.
Small problem is though that the current implementation is already used in the wild (at our office, for instance). So the current location %USERPROFILE%/OpenVPN/config/*.ovpn should be searched as well (at least for one 2.x release), so current deployments don't break.
We actually discussed the config file directory's location quite a bit. We would have preferred %APPDATA%\OpenVPN but decided not to use it as Windows hides %APPDATA% from directory listings (correct?). So we thought that following best practices in this case would have increased our support burden considerably. If I recall correctly the problem can be fixed with filesystem ACLs, but we did not want to mess with those, either.
Often the way applications deal with the invisibleness of AppData is to put a shortcut to their configuration directory in the start menu. I think a more elegant solution is to have a menu item in the application for "open configuration directory in explorer". Really though, if the average user needs to be opening the configuration directory that strikes me as a bigger problem and suggests that the UI is lacking. I believe there is already an outstanding issue for making it so users can easily add configuration files via the UI rather than file explorer, so perhaps once that is addressed the expectation that the user will need to open a config folder for anything but extreme cases will go away?
@MicahZoltu : the workarounds you suggest sound reasonable. Once the pull request Functionality to import configuration file from the command line has been merged, the location of config files will matter less than now. That said, importing OpenVPN config files is pretty tricky when there are references to external files (e.g. certificates, scripts, auth-user-pass files). We will probably always need an option to import config files manually, and for that proper documentation and the workarounds you suggest are probably good enough.
I think until the GUI has a proper config editor that can handle dependent files, create configs from a dialog, edit scripts etc., the users will have to directly manipulate files in the config folder. Hence the need to treat them like personal documents kept in a "visible" location.
creating configs from scratch is a bit weird.
for example, iphone, android do not have anything, just "import" from url and everybody is hust happy with that.
I think it adds some extra security and convenience if the ovpn file is stored in %USERPROFILE%\OpenVPN\Config since this ovpn filed is linked to the user, not to the machine. Or at least it is such in my domain. So I prefer that other users who log in don't even see that there's an ovpn available if they didn't get a personal one. People who prefer ovpns linked to a machine can still use %PROGRAMFILES%\OpenVPN\Config.
@jupsoleil %AppData% is per user. Also, machine wide config should go into %ProgramData%, not %ProgramFiles%
@MicahZoltu indeed you are right, I overlooked that! So your proposal is sound 👍 .
I found a document describing it quiet clearly. Developers best practice for Windows user profiles
%AppData% would be best, but be aware, that this could be an UNC path in a roaming profile environment. Which is most probably a network drive. Software like OpenVPN which modifies the network connection of the system could break the access to the directory.
Even better would be to use an own environment variable (e.g. OPENVPNPROFILE) with the fallback to %AppData%.
@selvanair Can you shed some light on what discussions resulted in this getting closed as not planned? The conversation above seems to imply that there was weak support for fixing this once the UI had better import options.
The current behavior is still wrong and I think there should be a plan to fix it eventually. I'm generally OK with projects taking the time they need to get things fixed (in this case, more than 5 years it seems) but I don't think this should just be left unfinished forever.
The premise of this thread that we are not following best practices by keeping configs in user-visible folders stems from a misunderstanding that config files are internal assets of this application. That's not the case:
(1) In the current design of the GUI, config files are user's assets --- something they can create, delete and edit outside of the application using independent tools --- not some internal configuration that belongs to the application.
(2) We do not have a fully functional config import feature that will automatically install not just config files but their dependencies too -- cert, key files, scripts etc. Users are required to copy those files into the config folder manually. So, "hiding" user configs in a hard to find location like %....APPDATA% is not appropriate for this application in its current state.
If interested in addressing (2) open a separate issue or PR.
In that case, if these are truly user assets, then a save/open dialog should be used to let the user choose where to read/write files to. The idea is that %USERPROFILE% is a directory the user controls and they can choose to write directly to it, in a subfolder, or elsewhere. Apps should not be hard coding any reads/writes to that directory.
If you want a fixed location that the app decides/controls structure of, then APPDATA/<product> or LOCALAPPDATA/<product>.
If you want user controlled files, then an open/save dialog which can reasonably default to USERPROFILE and you can remember their previous location for future dialog defaults or auto-reply (e.g., recent items list, reload on restart).
Hi,
On Sat, Dec 17, 2022 at 08:53:22AM -0800, Micah Zoltu wrote:
If you want user controlled files, then an open/save dialog which can reasonably default to
USERPROFILEand you can remember their previous location for future dialog defaults or auto-reply (e.g., recent items list, reload on restart).
We don't have resources to work on this any time soon.
If someone else wants to take a stab at contributing code, that might get things moving faster.
gert
-- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany @.***
