On Thu, Jun 7, 2018 at 5:10 PM, Nick Couchman <[email protected]> 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
