Alternative to using an iframe?

[Eric Amador <er...@gmail.com>]

Hello everyone,

This StackOverflow post, answered by Mike Jumper, convinced me that moving
away from using an iframe is the right thing to do.
https://stackoverflow.com/questions/33412605/how-to-use-
guacamole-in-my-own-django-project

However, I've gotten a bit stuck on figuring out what I need to do to
replace the iframe we currently embed into webpages for our end users to
have easy access to their RDP sessions. Currently, we're able to use
iframes to point to a (cross-domain) URL that looks something like
https://our-guac-server.com/guacamole/?username=<guac_
connection_username>&password=<guac_connection_password>. This is
convenient for us because the Guacamole/RDP credentials and connection
information are created asynchronously while our end users' remote desktop
instances are starting up on AWS EC2. We stick this connection information
into the Postgres AWS RDS database that Guacamole uses for authentication,
and then when the end users' are ready to connect to these instances, we
can template the above URL to have the iframe automatically connect to a
view of their remote desktop session when visiting the appropriate URL on
our website.

I would greatly appreciate some guidance on how to reproduce this behavior
using the JavaScript API instead of an iframe. I've tried pointing the
Guacamole.HTTPTunnel
URL in the example JS API code to /tunnel on our guacamole server with no
results. I'm not even sure if the support that I'm looking for in this
default tunnel is built in. Will this involve writing our own tunnel
servlet that consumes some query string parameters passed to it, like the
user's Guacamole credentials? I read all the documentation I could find,
and have been working to solve this problem for a few days now, to no avail.

Thanks for your help,
Eric Amador

Re: Alternative to using an iframe?

[Mike Jumper <mi...@guac-dev.org>]

On Mon, Aug 29, 2016 at 12:37 PM, Eric Amador <er...@gmail.com> wrote:
> Hello everyone,
>
> This StackOverflow post, answered by Mike Jumper, convinced me that moving
> away from using an iframe is the right thing to do.
> https://stackoverflow.com/questions/33412605/how-to-use-guacamole-in-my-own-django-project
>

Ah, Mike Jumper. What a guy.

> However, I've gotten a bit stuck on figuring out what I need to do to
> replace the iframe we currently embed into webpages ...
> I would greatly appreciate some guidance on how to reproduce this behavior
> using the JavaScript API instead of an iframe. I've tried pointing the
> Guacamole.HTTPTunnel URL in the example JS API code to /tunnel on our
> guacamole server with no results.

You can definitely do what you intend, but I would recommend looking
beyond hacking together a solution which works around the auth system
(more on this below). If you are looking to embed a remote display
within your own web pages, where the connection is determined
according to your own rules and the interface functions according to
your own design, then you should look toward writing your own
application leveraging the Guacamole APIs.

You will end up with a better and more stable system.

> I'm not even sure if the support that I'm looking for in this default tunnel is built in.

Both the HTTP and WebSocket tunnels are standard parts of the Guacamole API.

> Will this involve writing our own tunnel servlet that consumes some query string
> parameters passed to it, like the user's Guacamole credentials? I read all the
> documentation I could find, and have been working to solve this problem for a
> few days now, to no avail.
>

It can. Whether it does (and whether that makes sense) is completely
up to you, but I believe this would be the right choice.

It's important to remember that Guacamole itself is a web application
built upon the Guacamole APIs. Those core APIs are what provide the
functionality that comes to mind when you think of clientless remote
desktop, and they are available for you to do with as you wish. Things
like the authentication subsystem, and even the concept of a
"Guacamole user", are specific to our implementation of that web
application. You do not need to do everything the same way, and you do
not need to embed the entire web application to get what you're
looking for.

It may seem simpler to use the web application as-is and hack around
any parts of that app that don't match your use case, but needing to
do so should set off architectural alarm bells. It is better in the
long run to write your own app using the Guacamole APIs directly. This
is exactly the reason those APIs are kept separate.

- Mike


On Mon, Aug 29, 2016 at 12:37 PM, Eric Amador <er...@gmail.com> wrote:
> Hello everyone,
>
> This StackOverflow post, answered by Mike Jumper, convinced me that moving
> away from using an iframe is the right thing to do.
> https://stackoverflow.com/questions/33412605/how-to-use-guacamole-in-my-own-django-project
>
> However, I've gotten a bit stuck on figuring out what I need to do to
> replace the iframe we currently embed into webpages for our end users to
> have easy access to their RDP sessions. Currently, we're able to use iframes
> to point to a (cross-domain) URL that looks something like
> https://our-guac-server.com/guacamole/?username=<guac_connection_username>&password=<guac_connection_password>.
> This is convenient for us because the Guacamole/RDP credentials and
> connection information are created asynchronously while our end users'
> remote desktop instances are starting up on AWS EC2. We stick this
> connection information into the Postgres AWS RDS database that Guacamole
> uses for authentication, and then when the end users' are ready to connect
> to these instances, we can template the above URL to have the iframe
> automatically connect to a view of their remote desktop session when
> visiting the appropriate URL on our website.
>
> I would greatly appreciate some guidance on how to reproduce this behavior
> using the JavaScript API instead of an iframe. I've tried pointing the
> Guacamole.HTTPTunnel URL in the example JS API code to /tunnel on our
> guacamole server with no results. I'm not even sure if the support that I'm
> looking for in this default tunnel is built in. Will this involve writing
> our own tunnel servlet that consumes some query string parameters passed to
> it, like the user's Guacamole credentials? I read all the documentation I
> could find, and have been working to solve this problem for a few days now,
> to no avail.
>
> Thanks for your help,
> Eric Amador