guacamole-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nick Couchman (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (GUACAMOLE-221) Parameter prompting within client interface
Date Wed, 22 Mar 2017 14:00:47 GMT

    [ 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=#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)

Mime
View raw message