Hi,
On Sat, Nov 25, 2017 at 5:04 PM, Jonathan K. Bullard <jkbull...@gmail.com>
wrote:
> 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.
>
This looks good, though sending title and subtitle in separate echo
commands would make it simpler: no comma delimited text needed
and more space left for the message --- see below on command
length limitation.
Further, PUSH_REPLY is currently comma delimited, so this will
complicate push processing within openvpn. I would stick with the
current space delimited format in management interface exchanges
as its also consistent with the config file syntax.
>
> 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"
>
>
I believe that's how echo is delivered now -- everything that follows echo
is a single blob of text for openvpn, leaving its interpretation to the GUI.
> * Everything is UTF-8-encoded.
>
All text within openvpn and config/ccd files and management
communication are already utf-8, isn't it? So this should just work.
>
> * 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.
>
AFAIK, there is a 255 char limitation in the command parser, so longer
echo messages are not be possible. But we could allow concatenation
of multiple echo messages if required.
>
> * 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.
>
Comma delimited text is no easier to parse than space delimited one's
even if spaces are more common in text 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
>
I think, currently, openvpn does not escape anything in strings that it
writes to the management interface though it expects strings read from
the interface be escaped with a backslash. So this will require some
changes to openvpn itself.
>
> --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..."
>
Support for embedded newlines also will need some changes to the
management related code in openvpn as the current protocol is
line based and embedded '\n' is not recognized as such.
>
> 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.
>
I would vote for using space as that is consistent with the exisiting
management protocol even if that requires the use of quotes and/or
escaped spaces. Much of quote/escape may be avoided using a
simple msg structure. And, do not support embedded new lines.
Instead have multiple "echo msg .. " commands to send multiple
lines.
Of course it would prevent lines longer than about ~200 characters,
but without changes to the management protocol, option parsing,
and possibly PUSH processing, its not possible to send very long
echo commands anyway.
Short messages are enough for displaying an "motd"-like message
when the connection comes up. If necessary, we could consider
embedded urls or some sort of 'echo msg-url url' that you proposed
above for longer messages.
Selva
------------------------------------------------------------------------------
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
