[
https://issues.apache.org/jira/browse/GUACAMOLE-221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15935821#comment-15935821
]
Michael Jumper commented on GUACAMOLE-221:
------------------------------------------
{quote}
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.
{quote}
There may be user interface improvements that could solve that issue.
{quote}
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.
{quote}
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.
{quote}
Beyond that, I'm still struggling with how to inject the prompt into the stream
of making the connection.
{quote}
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.
{quote}
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.
{quote}
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.
{quote}
I suppose I could do this and loop through until the $\{GUAC_PROMPT}
{quote}
You'd want to build up the entire set of parameters which need prompting, not
stop at the first.
{quote}
There's not really a good way to tell what type of data you're prompting for.
{quote}
Ah, but there is! See the JSON files in:
https://github.com/apache/incubator-guacamole-client/tree/3407586642f08cc9ffbe682fc8aa30a111fa0a66/guacamole-ext/src/main/resources/org/apache/guacamole/protocols
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.
{quote}
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.
{quote}
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: https://issues.apache.org/jira/browse/GUACAMOLE-221
> Project: Guacamole
> Issue Type: New Feature
> Components: guacamole
> Reporter: Michael Jumper
>
> {panel:bgColor=#FFFFEE}
> *The description of this issue was copied from
> [GUAC-335|https://glyptodon.org/jira/browse/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
(v6.3.15#6346)
