I'm a big fan of WinSCP and have been using it for some years.
I am evaluating its use in a restricted terminal/virtual-desktop environment, and trying to configure it in such a way to restrict functionality when run from a specific terminal server (i.e. restrict client features to only those that I want my terminal users to be able to do). From that restricted environment, my users occasionally need to browse to a specific, fixed FTP server location.
Many of the restrictions I would like are already possible in WinSCP. Essentially setting to
Explorer interface, with no toolbars, and downloads fixed to a specific local directory meets most of my needs.
I have created an INI file based on the preferences that I want my users to have, I've added
Access=read
to each of the INI file sections, and I've restricted write permissions to the file. The user entry point is a published desktop shortcut which runs
winscp.exe /ini=x:\pathto\readonly.ini ftp://target-server
.
However, due to a couple of UI elements, it is still trivial to bypass the client restrictions, and in fact now even easier to bypass the environment's
existing restrictions.
As such, I wonder if you would consider adding some extra INI-file preference values which:
- Prevent opening the Preferences dialog: This would prevent the terminal users from making changes to the restricted preferences during their session (even though they are already not persisted to the read-only INI file), so only the settings in the INI file are allowed.
- Prevent opening the Custom Commands dialog: Currently, restricted users can use this to open any local application (e.g. cmd.exe), and can use this as a jump-off point to further bypass additional restrictions on the terminal server.
- Prevent opening the Session Manager dialog: Currently, restricted users can use this to open sessions to any remote server. Even with Tabs disabled and all toolbars hidden, a user can still do CTRL+N (for example) and bring this window up.
- Prevent showing the docking panel right-click context menu: Even with all the toolbars hidden, a user can simply right-click the directory tree and turn them all back on, which re-exposes all the functionality I was trying to restrict by hiding them. (There is also a 1-pixel gutter between the title bar and the file list view panel which can also be right-clicked.)
I figure that, if agreeable, the first three would be easy enough to implement -- a boolean preference check at the top of
DoPreferencesDialog
,
DoCustomCommandDialog
and
DoLoginDialog
could return
false
if the relevant preference was set. The fourth should also be straightforward -- a similar boolean preference check at the point where the context menu is triggered -- but I can't find where that is. In any case, I lack the tools to make a custom build with these changes in place.
For posterity, I used to publish a desktop shortcut to Internet Explorer, which offered many Active Directory Group Policy settings to heavily restrict access, but IE is no more and Edge's FTP browsing leaves a lot to be desired.