On Sat, Jun 4, 2016 at 7:36 PM, Nick Couchman <[email protected]> wrote:
> First, I want to say that Guacamole is awesome. I've followed since the > very early days of development, and just recently dug back into the > project. It's fantastic, and I think we have several potential areas to > use it across the company - between enabling remote desktop connectivity on > tablets and ultra books, and application delivery, it is proving to be > quite useful. > Hey, Nick! Glad to see you're still around. > I'm running into one situation, specifically when doing application > delivery, that I could use some help with. In this particular instance I > have Guacamole set up with the No Auth plugin, and am using it to connect > to Windows-based hosts over RDP. No credentials are being stored, and the > users must authenticate with their AD credentials to the Windows system, so > it's a pretty low-risk scenario for using No Auth. In virtually all cases, using NoAuth is a hack and a bad idea. More on this later. What I'd really like to do, however, is set up specific hostnames that > redirect to a Guacamole connection. I'm using Apache to front the HTTP > connections and using mod_proxy to connect to Tomcat. Let's say my server > is guacamole.example.local, but that I want > <application>.apps.example.local to redirect to > guacamole.example.local/guacamole/#/client/<connection id>. I've tried > several Apache incantations to get this working, and have not stumbled > across the correct configuration. My most recent set of configs looks like > this: > > <VirtualHost *:80> > ServerName erp.apps.example.local > ProxyPass / http://localhost:8080/guac/ flushpackets=on > ProxyPassReverse / http://localhost:8080/guac/ > RewriteRule / "/#/client/SUZTIExpdmUAYwBub2F1dGg=" [NE] > ProxyPassReverseCookiePath /guac / > </VirtualHost> > > This will not work, because it is not the server that needs to read that URL; it is the JavaScript code of the web application. It is the duty of the page handling the /#/client/... URL to decode the base64 identifier and use it to provide the correct HTTP parameters when making the connection request. Even if we did not use these base64 identifiers, it is unlikely such an approach would work for any application using these sorts of "/#/..." URLs, as everything following the hash is handled within the browser only. You cannot rely on an HTTP client sending anything following a hash character back to the server. The part following the hash of a URL is known as the "fragment identifier". >From the Wikipedia page covering this[1]: "... Clients are not supposed to send URI-fragments to servers when they retrieve a document, and without help from a local application (see below) fragments do not participate in HTTP redirections. ..." BUT! All is not lost. You can do this, and you can do it without using NoAuth (the way it should be done 99.99999% of the time, IMHO). Consider: 1) A Guacamole extension can leverage just about anything present in an HTTP request for the sake of authentication and authorization. You can use the content of the HTTP request to determine what data is available to the user, ideally while validating that they are indeed authenticated to access the system. You could use the "Host" header to determine virtual host[2] they accessed, for example. 2) If a user has access to only one connection, they will be taken to that connection automatically. You won't need to include the client identifier in the URL if they only have one connection to begin with. If you embrace the authentication system (GOOD!) instead of bypassing the authentication system (BAD!), and leverage it to both provide your users with what is requested and restrict them to only what they are allowed, you will have a better and safer system that does what you need. Thanks, - Mike "I really think we should stop supporting NoAuth" Jumper [1] https://en.wikipedia.org/wiki/Fragment_identifier [2] https://en.wikipedia.org/wiki/Virtual_hosting
