[GUACAMOLE-422] Timezone Redirection

• Type: Improvement
• Status: Resolved
• Priority: Minor
• Resolution: Implemented
• Fix Version/s: 1.1.0
• Component/s: guacamole-client, guacamole-server, RDP, SSH
• Assignee: Nick Couchman
• Reporter: Nick Couchman
• Created: 23/Oct/17 19:09
• Updated: 03/Aug/19 11:38
• Resolved: 03/Aug/19 11:38

Description

It would be nice to support full timezone redirection from the browser client through to a RDP server. There are a few challenges to making this work:

• Detect timezone at browser and pass that through to the servlet side, somewhere.
• Handle timezone on servlet side and pass through to guacd
• Allow guacd to process the timezone and add it to the RDP connection.

For browser side, there is a JavaScript library, jstz, that can do the detection and provide the timezone. Handling it on the servlet side, however, requires some way to pass it in during the connection. This could be done as a parameter at login time, or a separate api call.

Once it is into the servlet, there has to be a way to process it as a parameter to a connection. I'm thinking maybe a token, but not sure that's the right way to go. Once it's on the connection it can pass through to guacd.

The biggest issue, I think, is then getting guacd to be able to add it to a FreeRDP connection. From my looking at the current FreeRDP source code (stable-1.1 branch), FreeRDP currently detects the timezone on the system where it's running, first using the TZ variable, then looking at /etc/localtime and/or /etc/TZ on the system. This means that it's always going to redirect the timezone of the system where guacd is running, and not the timezone of the browser. Unfortunately there don't seem to be any available functions for sending FreeRDP a string representation of a timezone and having it process it that way, and all of the timezone information is located in the FreeRDP .c file, making it difficult to write a method for handling this without duplicating a lot of code and all of the timezone tables. So, not entirely sure the best route on that angle at this point, but we'll see.

Any input on whether this is a reasonable thing to address, or a corner-case not worth handling?

Issue Links

• causes: GUACAMOLE-815 Duplicate "timezone" parameter definition and translation
• is duplicated by: GUACAMOLE-854 Debug level guacd logs spammed with "Handler not found for"