[
https://issues.apache.org/jira/browse/GUACAMOLE-422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16499185#comment-16499185
]
Nick Couchman commented on GUACAMOLE-422:
-----------------------------------------
{quote}
Yeah, it might be ugly. If there is no way to programmatically inform FreeRDP
of the desired timezone, but it checks a "TZ" environment variable, we may be
able to still achieve this by setting that variable when the initial connection
is established. Each connection is isolated within its own process, and thus
has its own environment.
{quote}
Yeah, I just submitted a PR, and that's the route I ended up going. It's how
the SSH connections will work, too, so it isn't all bad, even if it does feel a
little crude.
{quote}
What about:
https://github.com/FreeRDP/FreeRDP/blob/851f0979d5b0b45a7595cab7ab1dd2d41d4a73d1/include/freerdp/settings.h#L875-L878
{quote}
Yes, you would think "aha, here's how I can do it." But, alas, no. The
ClientTimeZone field is in some sort of special format, and there's a good bit
of code that does the translation from UNIX time to that format:
https://github.com/FreeRDP/FreeRDP/blob/stable-1.1/libfreerdp/locale/timezone.c
Basically, that file has a translation table that it uses to look up the
timezone from the various standard time formats (e.g America/Los_Angeles) to
the time zone format expected by RDP. And, unfortunately, the FreeRDP API does
not provide any standard way to translate it - most of the functions used for
it are not provided in header files that can be leveraged by anything external,
particularly when it comes to the translation table, so using the functions
there would, as far as I can tell, require completely rewriting the translation
tables. You're welcome to take a look and tell me if I'm overlooking
something, but I've traced around those function calls and can't seem to find a
way to call any of them in such a way that would just let me feed it a standard
timezone and have it spit out the RDP identifier on the other end.
> Timezone Redirection
> --------------------
>
> Key: GUACAMOLE-422
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-422
> Project: Guacamole
> Issue Type: Improvement
> Components: guacamole-client, guacamole-server, RDP, SSH
> Reporter: Nick Couchman
> Assignee: Nick Couchman
> Priority: Minor
>
> 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?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
