Hi,
On Sat, Nov 25, 2017 at 2:21 PM, Gert Doering <g...@greenie.muc.de> wrote:
> I missed something in your list, which *I* would like to see for
> my users - a way to send a message to the GUI to display in a popup
> window, intended for the users to see.
>
> Examples could be stuff like
>
> "you are using a server that will be going away soon, please get
> an updated profile from your system administrator"
>
> (like, when having to migrate due to CA rollover)
>
> or
>
> "your OpenVPN is old and has known security issues, please migrate
> to version 2.4.4"
>
> or even
>
> "please change your Tunnelblick settings to enable OpenVPN 2.4,
> for better performance and less battery usage (AEAD)"
>
>
> (typically controlled by a --client-connect script on the server side
> which looks at incoming IV_ attributes and decides what to send, whether
> to send it on every connect or just once a week, etc. - but that's
> somewhat out of scope, just to give a bit more background on what I think
> how I'd use it)
>
>
> Originally, I thought
>
> push echo 'my message'
>
> would do exactly this, but I've since learned that this is more complicated,
> so we'll need to define a message type
>
> push echo 'message this is my message'
>
> or something, agree on max length, encoding, dialog behaviour (shall it
> be a tray message or non-modal dialog thing? do we want to have options to
> select either?)...
>
>
> Since I'm just a demanding user, I leave the specifics of that to you :-)
> (I'm sure Arne will have some ideas as well)
How about:
- "echo message-window,title,subtitle,text": Display a non-modal
popup window with title "title", subtitle "subtitle", text "text" and
a localized "OK" button.
and
- "echo message-notification,title,subtitle,text": Display the
"title", "subtitle", and "text" in the macOS "Notification Center"
[1]. The notification would persist until the user closes it. The
advantages with this as opposed to a non-modal popup window are that
it doesn't interrupt the user's workflow and honors a user's "do not
disturb" status (on macOS, anyway -- for example, while showing a
slideshow or other presentation). For Windows I think it would be a
"notification" in the taskbar area [2], but that's just a guess (I'm
not not sure that has the ability to show a subtitle).
If we want to get fancy, we could do:
- "echo window-url,url": Display a window with the contents of
"url" and a localized "OK" button. On macOS this would probably not be
a new browser window or tab, but would instead be a new Tunnelblick
window that displays what Safari would show (sandboxed to disallow
JavaScript and "file://").
or even
- "echo window-url,url1,url2,url3,button1text,button2text":
Display a window with the contents of "url1" and two buttons labelled
button1text and button2text. If the window is dismissed with button1,
a GET request with url2 is made; if the window is dismissed with
button2 or for any other reason, a GET request with url3 is made. The
server would be responsible for localization of the button text. As an
example, this could allow the user to "agree" or "disagree" with the
VPN's terms of use; the VPN connection could then be terminated by the
server if the user disagreed (assuming the webserver and OpenVPN
server communicated this, of course).
Encoding, Field Separators, and Escaping
I propose the following _for_all_echo_commands_ (it would be nice to
be able to centralize parsing), which I think makes quoting
unnecessary and simplifies parsing. Quoting would still be done at the
"echo" level:
echo "command-and-all-of-the-command's-arguments"
* Everything is UTF-8-encoded.
* Length: I would code to handle anything less than a couple GB :
). Probably this will be limited by what OpenVPN can store in the
"echo" buffer(s) but I'm not sure if there is a per-echo limit or an
overall limit on the size of the stored echos -- they get stored until
the GUI requests them. More practically, titles, subtitles, and
notification text should be short so they display reasonably, but
window text and URLs could be longer.
* The field separator is a comma, just as the management interface
uses commas to separate fields.
(That's _not_compatible_ with Selva's proposed "setvar name
value", which would need to become "setvar,name,value".) Spaces are
good when the fields aren't likely to have spaces, but titles,
subtitles, and text are more likely to have spaces than commas.
* The escape character should be a backslash (0x5C).
* Escape sequences would be limited to \\, \, and \n. Everything
else that needs escaping would be escaped at and handled at a higher
level. That may mean you need to double-backslash something like
--echo "message-window,This is the title, This is the
subtitle,This is the first line of text\\nThis is the second line of
text.\\nThis is the third..."
so what gets sent through the management interface has two "\n"
sequences, but only one actual linefeed (which terminates the "echo"
command).
I'd be (somewhat reluctantly) OK with using the space character as a
field separator but that makes it necessary to add the ability to
enclose fields in quotes, which make things complicated.
Note that using a field separator or escape character with an ASCII
code above 0x3F (such as backslash) makes it hard to parse strings
without Unicode-aware string routines, but I macOS has them, and I
assume Windows has, too.
Best regards,
Jon
[1] https://support.apple.com/en-us/HT204079
[2]
https://msdn.microsoft.com/en-us/library/windows/desktop/ee330740(v=vs.85).aspx
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users
