Uploaded image for project: 'Guacamole'
  1. Guacamole
  2. GUACAMOLE-47

Get client hostname for use in guac RDP session

    Details

    • Type: New Feature
    • Status: Resolved
    • Priority: Minor
    • Resolution: Done
    • Affects Version/s: 0.9.9
    • Fix Version/s: 0.9.12-incubating
    • Component/s: guacamole-client
    • Labels:
      None

      Description

      The "Clientname" variable should show the client name connected to the Apache server. I am not a programmer, but if I am understanding this right, there is a java servlet that could gather that information so it can be used in the Guacamole session.

      http://docs.oracle.com/javaee/6/api/javax/servlet/ServletRequest.html#getRemoteHost()

      Is this possible?

        Activity

        Hide
        nick.couchman@yahoo.com Nick Couchman added a comment -
        Show
        nick.couchman@yahoo.com Nick Couchman added a comment - Pull request 109 created: https://github.com/apache/incubator-guacamole-client/pull/109
        Hide
        nick.couchman@yahoo.com Nick Couchman added a comment - - edited

        So, code should be ready for review and to try out - if people think I should submit a pull request, I will, or if you'd rather review in my git repo before that, that's fine by me. I think I messed up one of the contribution guidelines in that I committed to the master branch instead of creating a separate branch, but hopefully that's not a show-stopper. If it is, I'll redo it. Here's the repo URL:

        https://github.com/necouchman/incubator-guacamole-client

        To use it, compile and load up the guacamole code. The two new tokens are:

        • GUAC_REMHOST
        • GUAC_REMIP

        If you're connecting to Guacamole directly through Tomcat this should work with no additional configuration, aside from using the tokens in the connection configuration.

        If you're using a proxy, you'll need to do one of two things:
        1) Define the X-Guacamole-Client-Hostname and/or X-Guacamole-Client-IP headers. Here's an example for Apache that uses the REMOTE_HOST and REMOTE_ADDR headers:

        RequestHeader set X-Guacamole-Client-Hostname %{REMOTE_HOST}s
        RequestHeader set X-Guacamole-Client-IP %{REMOTE_ADDR}s
        

        2) Configure Tomcat to allow the X-Forwarded-For header to be passed through. This is done with the following configuration in server.xml. Remember this will only ever have the IP address - X-Forwarded-For never has the hostname.

                <Valve className="org.apache.catalina.valves.RemoteIpValve"
                       internalProxies="127.0.0.1"
                       remoteIpHeader="x-forwarded-for"
                       remoteIpProxiesHeader="x-forwarded-by"
                       protocolHeader="x-forwarded-proto" />
        

        Note that you need to set internalProxies to the list of hosts that are proxying to Guacamole. In my case I'm just doing it on the local system, so I have 127.0.0.1.

        Show
        nick.couchman@yahoo.com Nick Couchman added a comment - - edited So, code should be ready for review and to try out - if people think I should submit a pull request, I will, or if you'd rather review in my git repo before that, that's fine by me. I think I messed up one of the contribution guidelines in that I committed to the master branch instead of creating a separate branch, but hopefully that's not a show-stopper. If it is, I'll redo it. Here's the repo URL: https://github.com/necouchman/incubator-guacamole-client To use it, compile and load up the guacamole code. The two new tokens are: GUAC_REMHOST GUAC_REMIP If you're connecting to Guacamole directly through Tomcat this should work with no additional configuration, aside from using the tokens in the connection configuration. If you're using a proxy, you'll need to do one of two things: 1) Define the X-Guacamole-Client-Hostname and/or X-Guacamole-Client-IP headers. Here's an example for Apache that uses the REMOTE_HOST and REMOTE_ADDR headers: RequestHeader set X-Guacamole-Client-Hostname %{REMOTE_HOST}s RequestHeader set X-Guacamole-Client-IP %{REMOTE_ADDR}s 2) Configure Tomcat to allow the X-Forwarded-For header to be passed through. This is done with the following configuration in server.xml. Remember this will only ever have the IP address - X-Forwarded-For never has the hostname. <Valve className= "org.apache.catalina.valves.RemoteIpValve" internalProxies= "127.0.0.1" remoteIpHeader= "x-forwarded-for" remoteIpProxiesHeader= "x-forwarded-by" protocolHeader= "x-forwarded-proto" /> Note that you need to set internalProxies to the list of hosts that are proxying to Guacamole. In my case I'm just doing it on the local system, so I have 127.0.0.1.
        Hide
        nick.couchman@yahoo.com Nick Couchman added a comment -

        Okay, I've got an initial implementation of this going, which I'll link to after I get it onto GitHub and make sure all of my changes match the contribution guidelines. There are some caveats:

        • The easiest way to make this work is to grab the HttpServletRequest.getRemoteHost() and getRemoteAddr() values and use those. It's a little more complicated than just that, but that gets what the servlet has as the remote host. Unfortunately this doesn't always work as expected, particularly in situations where Guacamole/Tomcat is behind a reverse proxy, like Apache/mod_proxy or Nginx.
        • Dealing with the reverse proxy issue isn't too terribly difficult - there's a X-Forwarded-For header that is set by Apache's mod_proxy that can be passed through to the servlet. This has a couple of catches, though - first, it only passes through the IP address that it is forwarding for (essentially the original REMOTE_ADDR request header), and, second, you have to do a little bit extra Tomcat configuration to allow it to be passed through (via the RemoteIP valve).
        • To deal with proxy scenarios and get both the original REMOTE_HOST and REMOTE_ADDR values, you have to set up custom headers in whatever you're using to proxy, and the Guacamole code has to deal with it. I've written the code to use the custom X-Guacamole-Client-Host and X-Guacamole-Client-IP headers.

        I'm actually going to deal with these in reverse order - check for the custom headers, first, check for the X-Forwarded-For header, next, and finally use the getRemoteHost and getRemoteAddr methods.

        I'm happy to take comments from anyone off the bat - I'll post the forked GitHub code in a little while.

        Show
        nick.couchman@yahoo.com Nick Couchman added a comment - Okay, I've got an initial implementation of this going, which I'll link to after I get it onto GitHub and make sure all of my changes match the contribution guidelines. There are some caveats: The easiest way to make this work is to grab the HttpServletRequest.getRemoteHost() and getRemoteAddr() values and use those. It's a little more complicated than just that, but that gets what the servlet has as the remote host. Unfortunately this doesn't always work as expected, particularly in situations where Guacamole/Tomcat is behind a reverse proxy, like Apache/mod_proxy or Nginx. Dealing with the reverse proxy issue isn't too terribly difficult - there's a X-Forwarded-For header that is set by Apache's mod_proxy that can be passed through to the servlet. This has a couple of catches, though - first, it only passes through the IP address that it is forwarding for (essentially the original REMOTE_ADDR request header), and, second, you have to do a little bit extra Tomcat configuration to allow it to be passed through (via the RemoteIP valve). To deal with proxy scenarios and get both the original REMOTE_HOST and REMOTE_ADDR values, you have to set up custom headers in whatever you're using to proxy, and the Guacamole code has to deal with it. I've written the code to use the custom X-Guacamole-Client-Host and X-Guacamole-Client-IP headers. I'm actually going to deal with these in reverse order - check for the custom headers, first, check for the X-Forwarded-For header, next, and finally use the getRemoteHost and getRemoteAddr methods. I'm happy to take comments from anyone off the bat - I'll post the forked GitHub code in a little while.
        Hide
        zbonjour Zach Bonjour added a comment -

        Our core software must register workstations (based on MAC, computername, or clientname) before it allows a login. This allows the core software to tie the workstation to a location with location specific settings. Right now, I am setting the clientname variable as "guac-$

        {GUAC_USERNAME}

        ". This works, but not ideally. This allows the connection to the core but makes their location specific settings mobile. I would like to tie that clientname variable to the hardware, not the person using the hardware.

        Show
        zbonjour Zach Bonjour added a comment - Our core software must register workstations (based on MAC, computername, or clientname) before it allows a login. This allows the core software to tie the workstation to a location with location specific settings. Right now, I am setting the clientname variable as "guac-$ {GUAC_USERNAME} ". This works, but not ideally. This allows the connection to the core but makes their location specific settings mobile. I would like to tie that clientname variable to the hardware, not the person using the hardware.
        Hide
        nick.couchman@yahoo.com Nick Couchman added a comment -

        Could you clarify what your use-case is for this particular request - what are you wanting to do with the "Clientname" variable?

        Show
        nick.couchman@yahoo.com Nick Couchman added a comment - Could you clarify what your use-case is for this particular request - what are you wanting to do with the "Clientname" variable?
        Hide
        zbonjour Zach Bonjour added a comment -

        For further clarification, this is needed for variable client names that are not tied to the username.

        Show
        zbonjour Zach Bonjour added a comment - For further clarification, this is needed for variable client names that are not tied to the username.

          People

          • Assignee:
            mike.jumper Michael Jumper
            Reporter:
            zbonjour Zach Bonjour
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development