[jira] [Commented] (GUACAMOLE-221) Parameter prompting within client interface
[
https://issues.apache.org/jira/browse/GUACAMOLE-221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16217052#comment-16217052
]
Nick Couchman commented on GUACAMOLE-221:
-
Took a stab at this; code is waiting for review.
> 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
>Assignee: Nick Couchman
>
> {panel:bgColor=#EE}
> *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.4.14#64029)
[jira] [Commented] (GUACAMOLE-221) Parameter prompting within client interface
[
https://issues.apache.org/jira/browse/GUACAMOLE-221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15936357#comment-15936357
]
Nick Couchman commented on GUACAMOLE-221:
-
{quote}
There may be user interface improvements that could solve that issue.
{quote}
I'm happy to try stuff out if there are suggestions...
{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}
Yeah, I didn't think changing this was the correct route to go, and seems like
a lot of work, anyway.
{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.
...
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.
{quote}
Sorry, I think I used the term "stream" in a way that made you think I was
saying something I wasn't saying. I wasn't saying to do the prompting after
the connection had been initiated, I just meant, when the user clicks on the
connection they want to launch, you check for the GUAC_PROMPT token, throw
exceptions when you need information, triggering forms to be displayed on the
Angular side, then substitute those values back in and *then* start the
connection stream (the actual stream) with the full parameter set.
{quote}
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.).
{quote}
Kind of, although I think the current TokenFilter code runs before the actual
connnection starts, right? This is where other tokens are replaced with their
actual values, and I'm fairly certain that code runs on the servlet side before
the connection stream is actually established?
{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.
...
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.
{quote}
Yeah, I had already figured out a way to expose the field names, so no issue
there, but, as you point out, I don't really want to key on the field name to
pick out the field type. However, with the JSON files and REST service, what's
the best way to link field being prompted for on the servlet side with what
gets picked up on the Angular side? I'm currently focusing my efforts on the
TokenFilter.filter() method. I've modified the function slightly to take the
field name as input (in addition to the field value/token name), and this
allows me to pass the field name in to the prompt, but the filter method is
called my the filterValues() method, and this only has K/V pairs that don't
necessarily have any real link back to the type of field being represented.
Or maybe I need to go somewhere else besides the TokenFilter code??
Thanks for the hints.
> 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=#EE}
> *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 wi
[jira] [Commented] (GUACAMOLE-221) Parameter prompting within client interface
[
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/GUACA
[jira] [Commented] (GUACAMOLE-221) Parameter prompting within client interface
[
https://issues.apache.org/jira/browse/GUACAMOLE-221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15935275#comment-15935275
]
Nick Couchman commented on GUACAMOLE-221:
-
Oh, and the other thing I forgot about that I'm running into with the
prompting, particularly trying to use ${GUAC_PROMPT} in the current token
setup. There's not really a good way to tell what type of data you're
prompting for. So, presumably if you're going to be prompting for a password
you want to use the password field (especially the part where it hides what
you're typing), and if you're going to be prompting for the port you want a
numeric field that enforces that the selection/input be numeric. 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.
> 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=#EE}
> *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)
[jira] [Commented] (GUACAMOLE-221) Parameter prompting within client interface
[
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 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=#EE}
> *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)
