You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@guacamole.apache.org by Nick Couchman <vn...@apache.org> on 2018/06/08 00:10:11 UTC

Decoration and Connection Parameters

Okay, question here about using the decoration feature of the extensions
and accessing parameters.  I'm trying to write an extension that does both
the status checks and Wake-on-LAN on the hosts in each of the connections.
The connections are stored in the JDBC module, and I'm then implementing a
DelegatingConnection class in the WOL extension to check the status and
send the WOL packets.

However, when trying to check the status, I'm retrieving the configuration
of the connection in the constructor of the new DelegatingConnection
implementation, and none of the parameters have any value - the hostname
parameter, for example, keeps coming up null.

So, my questions are:
- Should it be possible for one extension to retrieve the full
GuacamoleConfiguration of a connection stored in another extension?
- If so, can someone provide some pointers on how to properly accomplish
this?

For reference my work is all in a branch of my fork of the guacamole-client
project, here:

https://github.com/necouchman/guacamole-client/tree/jira/513

and the extension is guacamole-auth-wol:

https://github.com/necouchman/guacamole-client/tree/jira/513/extensions/guacamole-auth-wol

I appreciate any pointers.

-Nick

Re: Decoration and Connection Parameters

Posted by Nick Couchman <vn...@apache.org>.
>
> - If so, can someone provide some pointers on how to properly accomplish
> > this?
> >
> >
> My understanding of WOL is that the IP address of the machine itself does
> not correspond to the address used for the magic packet (the MAC address):
>
> https://en.wikipedia.org/wiki/Wake-on-LAN#Magic_packet
>
> If this is the case, then access to the connection parameters is not
> necessary. I suggest instead leveraging the decoration aspect of the API to
> add additional attributes to connections, exposed through fields such that
> the admin can manually set the MAC address to be used for WOL. The
> technique involved would be similar to what is done with TOTP:
>
>
Sorry, I should have been more clear about why I'm trying to get the
hostname from the original configuration.  It isn't for the part that sends
the WOL packet, it's for the status check.  So, basically what I'm trying
to do with this extension is verify whether or not a host is up by opening
a connection to that host using the hostname and port number specified in
the configuration, and then also provide the ability to wake up the host
via the Magic Packet.  I do understand the hostname/IP is not required (or
even really useful) for sending the Magic Packet - you need the MAC
address, and, potentially, a IP broadcast address.  It's the status check
piece of it that I was trying to implement using existing information.  It
doesn't make a whole lot of sense to implement the status check using an
additional arbitrary attribute field that contains the hostname or IP when
that is already available in the configuration.

I could pass the status check through the web UI, using the REST API to
pull the information info the AngularJS webapp, and then feed that back to
a REST endpoint, but this seems like a lot of extra work/code, both writing
it and when running it, to get at a piece of information that might be just
as easily passed in the Java code on the backend.  Also, if you look at my
code you'll see I was playing with using the executor process scheduling to
have the status checked periodically and stored in an attribute - another
reason I wanted to do everything on the backend and not have to try passing
it all through the rest API.

Any hints on how to accomplish would be welcome.

Thanks,
Nick

Re: Decoration and Connection Parameters

Posted by Mike Jumper <mi...@glyptodon.org>.
On Thu, Jun 7, 2018 at 5:10 PM, Nick Couchman <vn...@apache.org> wrote:

> Okay, question here about using the decoration feature of the extensions
> and accessing parameters.  I'm trying to write an extension that does both
> the status checks and Wake-on-LAN on the hosts in each of the connections.
> The connections are stored in the JDBC module, and I'm then implementing a
> DelegatingConnection class in the WOL extension to check the status and
> send the WOL packets.
>
> However, when trying to check the status, I'm retrieving the configuration
> of the connection in the constructor of the new DelegatingConnection
> implementation, and none of the parameters have any value - the hostname
> parameter, for example, keeps coming up null.
>
> So, my questions are:
> - Should it be possible for one extension to retrieve the full
> GuacamoleConfiguration of a connection stored in another extension?
>

It MAY be possible, but this is specifically not guaranteed by the API. In
fact, the API guarantees the opposite. From the documentation for
Connection.getConfiguration():

"Returns the GuacamoleConfiguration associated with this Connection. Note
that because configurations may contain sensitive information, some data in
this configuration may be omitted or tokenized."

http://guacamole.apache.org/doc/guacamole-ext/org/apache/guacamole/net/auth/Connection.html#getConfiguration--

- If so, can someone provide some pointers on how to properly accomplish
> this?
>
>
My understanding of WOL is that the IP address of the machine itself does
not correspond to the address used for the magic packet (the MAC address):

https://en.wikipedia.org/wiki/Wake-on-LAN#Magic_packet

If this is the case, then access to the connection parameters is not
necessary. I suggest instead leveraging the decoration aspect of the API to
add additional attributes to connections, exposed through fields such that
the admin can manually set the MAC address to be used for WOL. The
technique involved would be similar to what is done with TOTP:

1) Attempt to set your custom attribute and verify whether this succeeds.
The underlying connection storage MAY support custom attributes (the JDBC
auth does), but is not required to do so. The only requirement is that
unsupported attributes are dropped, thus verifying that an attribute is NOT
dropped is sufficient to verify that the attribute is supported.
2) Declare the attribute by decorating the result of
getConnectionAttributes(), as any attempt to set the attribute will be
filtered out by the webapp otherwise.
3) Ensure that your decorated Connection properly validates the attribute
prior to storing it. Other than verifying that the attribute is declared,
no other validation is performed automatically. It's up to your extension
to perform any other necessary validation.

If this is NOT the case, and the IP address is indeed needed, I'd still
argue in favor of keeping the WOL address independent of the connection
parameters. The address of the machine that needs to be activated is not
necessarily identical to the address of the interface receiving the
connection.

- Mike