guacamole-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Jumper (JIRA)" <>
Subject [jira] [Commented] (GUACAMOLE-221) Parameter prompting within client interface
Date Wed, 22 Mar 2017 06:35:41 GMT


Michael Jumper commented on GUACAMOLE-221:

The simplest/obvious issue is that the parameter for port number is represented on the web
side as a numeric field and you cannot type "$\{GUAC_PROMPT}" into that field.

There may be user interface improvements that could solve that issue.

Next, I explored the option of adding a boolean field for prompting. ... Unfortunately there
are a couple of issues with this route. Probably the biggest roadblock is that in a lot of
places in the current code the parameters are stored in some Map-type object with a key/value
pair, and adding a second value (boolean prompt) isn't necessarily trivial.

Parameter key/value pairs are exactly how parameters need to be represented, at least at the
core API level. Within strictly the web application and extension subsystem, it's possible
to augment this, but I'm not convinced it's necessary. Making API changes should be the absolute
last resort.

Beyond that, I'm still struggling with how to inject the prompt into the stream of making
the connection.

The answer is: don't. You don't want to inject the prompt into the stream - that would break
the connection handling, muck with the 15 second timeout, etc. It would be disastrous.

My thought was to kind of follow how the initial Guacamole authentication handles challenges
- throw a new exception of some sort that triggers a form to be displayed with the field being
prompted for.

Yes! That's my thinking exactly. It's not possible (and shouldn't even be attempted) to inject
such prompting into the connection stream, but it can be done by adding a step to the connection
process. Currently, the tunnel is established immediately, and it's the tunnel which receives
additional connection information used by the handshake (screen size, supported mimetypes,
etc.). If this were separated out into an initial REST request. For example:

# POST to some endpoint with JSON containing the screen size, mimetypes, *and* a set of parameter
name/value pairs specified (if any)
# If parameters are required, an exception indicating this is thrown, and the REST service
produces a response describing the parameters required
# The interface displays a prompt similar to how the login interface functions
# Once the prompt is submitted, that POST is made again, this time with the specified parameters
included in that set
# Assuming the parameters are sufficient, no exception is thrown, and the REST service returns
some unique identifier for the tunnel which was created.
# The interface provides the unique identifier to the {{connect()}} function of the tunnel,
establishing the connection as normal. Due to the timeouts within the Guacamole stack, this
would need to be completed within 15 seconds of the final successful POST to that hypothetical
REST service.

I suppose I could do this and loop through until the $\{GUAC_PROMPT}

You'd want to build up the entire set of parameters which need prompting, not stop at the

There's not really a good way to tell what type of data you're prompting for.

Ah, but there is! See the JSON files in:

Those describe the structure and data types of the various parameters accepted by each known
protocol. These are all exposed via a REST service, and are used by the interface when generating
the connection parameter admin screen. The same thing could be done for the parameter prompting
- it would just be a subset of those parameters.

Without significant changes to the current token setup, this isn't really possible - some
minor changes would allow us to pass through the field name that's being prompted for and
make some determination based on that (if field name == password, use password field, if field
name == port, use numeric field, else use text field), but I'm not sure that's the cleanest
way to go.

You would definitely need to expose the field names being prompted, just as the initial auth
failure contains information describing the parameters required for login. You should definitley
*not* make assumptions based solely on parameter name - the Guacamole protocol stipulates
that these names are arbitrary. With the parameter schema JSON, however, the meaning of each
parameter for each known protocol is available, and no assumptions need be made.

> Parameter prompting within client interface
> -------------------------------------------
>                 Key: GUACAMOLE-221
>                 URL:
>             Project: Guacamole
>          Issue Type: New Feature
>          Components: guacamole
>            Reporter: Michael Jumper
> {panel:bgColor=#FFFFEE}
> *The description of this issue was copied from [GUAC-335|],
an issue in the JIRA instance used by the Guacamole project prior to its acceptance into the
Apache Incubator.*
> Comments, attachments, related issues, and history from prior to acceptance *have not
been copied* and can be found instead at the original issue.
> {panel}
> Some parameters, such as the username/password for VNC or RDP, are better entered manually
within the client when connecting rather than stored on the server in MySQL or {{user-mapping.xml}}.
> Storing secure data within parameters on the server side has security implications that
don't fit well with all use cases.
> Further, some connections would benefit if their settings can be modified locally before
connecting. A user could change the color depth or screen size of their RDP session, for example,
for the sake of a slower connection.

This message was sent by Atlassian JIRA

View raw message