[
https://issues.apache.org/jira/browse/GUACAMOLE-221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15935216#comment-15935216
]
Nick Couchman commented on GUACAMOLE-221:
-----------------------------------------
Well, I'm taking a stab at implementing some form of parameter prompting. In
the past, in one of the duplicate issues, I had suggested using some sort of
token to handle this - something like ${GUAC_PROMPT} that would trigger a
prompt (maybe via a certain kind of exception?) to get these values. But...I'm
running into a couple of issues with that.
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. So, it might work for hostname/username/password, but probably
would not work for the port - and, while port might be the one you're least
likely to want to prompt for, someone is going to want it, and I can foresee
situations where it'd be useful (VNC connections are the most obvious, as VNC
lacks multi-user session control on a single port).
Next, I explored the option of adding a boolean field for prompting. From a
schema perspective this would be pretty easy to do:
- In the JDBC extension, add a field in the guacamole_connection_parameter
table called parameter_prompt, which defaults to false.
- In the simple file configuration, add a "prompt" attribute to the "param" tag
- In LDAP, add another multi-valued attribute called guacConfigPromptParameter
that could be used to find attributes that would be prompted for.
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. In the file configuration
and LDAP cases this can be worked around by checking for the prompt attribute
and then setting the actual value to ${GUAC_PROMPT}, sort of combining this
method and the previous one; however, in the JDBC module it looks like values
are actually retrieved from the database in the Map<K, V> way, so, again,
adding a third column to that to see whether or not to prompt for it isn't
necessarily the most straight-forward. I guess I could do something similar to
the way I was doing the LDAP code and have a separate query to the DB for
promptable columns that grabs the parameter name and the boolean prompt value,
and then loops through those and prompts, but that's a decent amount of work.
So, any thoughts/opinions/directions on where to go with this, from the
perspective of how to key parameters for prompting? I'm happy to (attempt to)
do the legwork, just don't want to do a ton of work and then end up going a
completely different direction.
Beyond that, I'm still struggling with how to inject the prompt into the stream
of making the connection. 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. I
suppose I could do this and loop through until the ${GUAC_PROMPT} value isn't
found in any of the connection parameters, but is that even viable? Or is
there a simpler route to go to throw a prompt at the user, grab the info, and
then re-attempt the connection?
> 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)
