Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 5C25C200C05 for ; Mon, 23 Jan 2017 07:53:33 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id 5A983160B5E; Mon, 23 Jan 2017 06:53:33 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 07304160B53 for ; Mon, 23 Jan 2017 07:53:30 +0100 (CET) Received: (qmail 58479 invoked by uid 500); 23 Jan 2017 06:53:30 -0000 Mailing-List: contact commits-help@guacamole.incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@guacamole.incubator.apache.org Delivered-To: mailing list commits@guacamole.incubator.apache.org Received: (qmail 58470 invoked by uid 99); 23 Jan 2017 06:53:30 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 23 Jan 2017 06:53:30 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id A4B88180663 for ; Mon, 23 Jan 2017 06:53:29 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=6.31 tests=[KAM_ACCOUNTPHISH=4, KAM_ASCII_DIVIDERS=0.8, KAM_LAZY_DOMAIN_SECURITY=1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.999] autolearn=disabled Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id lgys9aQn_LWn for ; Mon, 23 Jan 2017 06:53:12 +0000 (UTC) Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with SMTP id 2AAC95FC18 for ; Mon, 23 Jan 2017 06:53:08 +0000 (UTC) Received: (qmail 57395 invoked by uid 99); 23 Jan 2017 06:53:07 -0000 Received: from git1-us-west.apache.org (HELO git1-us-west.apache.org) (140.211.11.23) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 23 Jan 2017 06:53:07 +0000 Received: by git1-us-west.apache.org (ASF Mail Server at git1-us-west.apache.org, from userid 33) id 4EACBDFC47; Mon, 23 Jan 2017 06:53:07 +0000 (UTC) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: jmuehlner@apache.org To: commits@guacamole.incubator.apache.org Date: Mon, 23 Jan 2017 06:53:09 -0000 Message-Id: In-Reply-To: References: X-Mailer: ASF-Git Admin Mailer Subject: [03/52] [partial] incubator-guacamole-website git commit: Add 0.9.11-incubating documentation. archived-at: Mon, 23 Jan 2017 06:53:33 -0000 http://git-wip-us.apache.org/repos/asf/incubator-guacamole-website/blob/2441fd18/doc/0.9.11-incubating/gug/duo-auth.html ---------------------------------------------------------------------- diff --git a/doc/0.9.11-incubating/gug/duo-auth.html b/doc/0.9.11-incubating/gug/duo-auth.html new file mode 100644 index 0000000..d85f9c7 --- /dev/null +++ b/doc/0.9.11-incubating/gug/duo-auth.html @@ -0,0 +1,101 @@ + +Chapter 8. Duo two-factor authentication + + + + +
+

Chapter 8. Duo two-factor authentication

Guacamole supports Duo as a second authentication factor, layered on top of any other + authentication extension, including those available from the main project website. The Duo + authentication extension allows users to be additionally verified against the Duo service + before the authentication process is allowed to succeed.

Important

This chapter involves modifying the contents of GUACAMOLE_HOME - + the Guacamole configuration directory. If you are unsure where + GUACAMOLE_HOME is located on your system, please consult Chapter 5, Configuring Guacamole before proceeding.

How Duo works with Guacamole

Guacamole provides support for Duo as a second authentication factor. To make use of + the Duo authentication extension, some other authentication mechanism will need be + configured, as well. When a user attempts to log into Guacamole, other installed + authentication methods will be queried first:

Only after authentication has succeeded with one of those methods will Guacamole reach + out to Duo to obtain additional verification of user identity:

If both the initial authentication attempt and verification through Duo succeed, the + user will be allowed in. If either mechanism fails, access to Guacamole is + denied.

Downloading the Duo extension

The Duo authentication extension is available separately from the main + guacamole.war. The link for this and all other + officially-supported and compatible extensions for a particular version of Guacamole are + provided on the release notes for that version. You can find the release notes for + current versions of Guacamole here: http://guacamole.incubator.apache.org/releases/.

The Duo authentication extension is packaged as a .tar.gz file + containing only the extension itself, + guacamole-auth-duo-0.9.11-incubating.jar, which must ultimately + be placed in GUACAMOLE_HOME/extensions.

Installing Duo authentication

Guacamole extensions are self-contained .jar files which are + located within the GUACAMOLE_HOME/extensions directory. To install + the Duo authentication extension, you must:

  1. Create the GUACAMOLE_HOME/extensions directory, if it + does not already exist.

  2. Copy guacamole-auth-duo-0.9.11-incubating.jar within + GUACAMOLE_HOME/extensions.

  3. Configure Guacamole to use Duo authentication, as described below.

Important

You will need to restart Guacamole by restarting your servlet container in order + to complete the installation. Doing this will disconnect all active users, so be + sure that it is safe to do so prior to attempting installation. If you do not + configure the Duo authentication properly, Guacamole will not start up again until + the configuration is fixed.

Adding Guacamole to Duo

Duo does not provide a specific integration option for Guacamole, but Guacamole's + Duo extension uses Duo's generic authentication API. To use Guacamole with Duo, you + will need to add it as a new "Auth API" application from within the "Applications" + tab of the admin panel of your Duo account:

Within the settings of the newly-added application, rename the application to + something more representative than "Auth API". This application name is what will be + presented to your users when they are prompted by Duo for additional + authentication:

Once you've finished adding Guacamole as an "Auth API" application, the + configuration information required to configure Guacamole is listed within the + application's "Details" section. You will need to copy the integration key, secret + key, and API hostname - they will later be specified within + guacamole.properties:

Configuring Guacamole for Duo

The application-specific configuration information retrieved from Duo must be + added to guacamole.properties to describe how Guacamole should + connect to the Duo service:

duo-api-hostname

The hostname of the Duo API endpoint to be used to verify user + identities. This will usually be in the form + "api-XXXXXXXX.duosecurity.com", + where "XXXXXXXX" is some arbitrary + alphanumeric value assigned by Duo. This value will have been generated + by Duo when you added Guacamole as an "Auth API" application, and can be + found within the application details in the "API hostname" field. + This value is required.

duo-integration-key

The integration key provided for Guacamole by Duo. This value will + have been generated by Duo when you added Guacamole as an "Auth API" + application, and can be found within the application details in the + "Integration key" field. This value is required and must be + EXACTLY 20 characters.

duo-secret-key

The secret key provided for Guacamole by Duo. This value will have + been generated by Duo when you added Guacamole as an "Auth API" + application, and can be found within the application details in the + "Secret key" field. This value is required and must be EXACTLY + 20 characters.

In addition to the above, you must also manually generate an + "application key". The application key is required by Duo's + authentication API, but is not provided by Duo. It is an arbitrary value meant to be + unique to each deployment of an application using their API.

duo-application-key

An arbitrary, random key which you manually generated for Guacamole. + This value is required and must be AT LEAST 40 + characters.

The application key can be generated with any method as long as it is sufficiently + random. There exist utilities which will do this for you, like + pwgen:

$ pwgen 40 1
+em1io4zievohneeseiwah0zie2raQuoo2ci5oBoo
+$

Alternatively, one quick and fairly portable way to do this is to use the + dd utility to copy random bytes from the secure random device + /dev/random, sending the data through a cryptographic hash + tool with a sufficiently-long result, like sha256sum:

$ dd if=/dev/random count=1 | sha256sum
+5d16d6bb86da73e7d1abd3286b21dcf3b3e707532e64ceebc7a008350d0d485d -
+$

Completing the installation

Guacamole will only reread guacamole.properties and load + newly-installed extensions during startup, so your servlet container will need to be + restarted before Duo authentication will take effect. Restart your servlet container + and give the new authentication a try.

+

Important

You only need to restart your servlet container. You do not need + to restart guacd.

guacd is completely independent of the web application + and does not deal with guacamole.properties or the + authentication system in any way. Since you are already restarting the + servlet container, restarting guacd as well technically + won't hurt anything, but doing so is completely pointless.

+

If Guacamole does not come back online after restarting your servlet container, + check the logs. Problems in the configuration of the Duo extension may prevent + Guacamole from starting up, and any such errors will be recorded in the logs of your + servlet container.

+ +
+ + + \ No newline at end of file http://git-wip-us.apache.org/repos/asf/incubator-guacamole-website/blob/2441fd18/doc/0.9.11-incubating/gug/faq.html ---------------------------------------------------------------------- diff --git a/doc/0.9.11-incubating/gug/faq.html b/doc/0.9.11-incubating/gug/faq.html new file mode 100644 index 0000000..32866d7 --- /dev/null +++ b/doc/0.9.11-incubating/gug/faq.html @@ -0,0 +1,86 @@ + +Appendix A. FAQ + + + + +
+

Appendix A. FAQ

A.1. Where does the name "Guacamole" come from?
A.2. What does "clientless" mean?
A.3. Does Guacamole use WebSocket?
A.4. I have Tomcat (or some other servlet container) set up behind a p roxy (like + mod_proxy) and cannot connect to Guacamole. Why? How do I solve this?
A.5. I connect to the internet through a web proxy, and cannot connect to + Guacamole. I cannot reconfigure the proxy. How do I solve this?
A.6. Can I buy special licensing of the Guacamole code base, such that I can use it + in my own product, without providing the source to my users, without + contributing back, and without acknowledging the project?
A.7. Can I pay for custom Guacamole work, or for help integrating Guacamole into my + product, if the open source nature and licenses are preserved?
A.8. How can I contribute to the project?
A.9. How can I become an official member of the project?
A.10. I think I've found a bug. How do I report it?
A.11. I need help! Where can I find some?

A.1.

Where does the name "Guacamole" come from?

The name was chosen arbitrarily from a random utterance in a conversation wi th + a member of the project.

When the project reached the point where it was growing out of the + proof-of-concept phase, and needed a real home on the internet, we needed to + think of a name to register the project under.

Several acronyms were toyed with and discarded. We tried anagrams, but all + were too wordy and complex. We considered naming the project after a fish or an + animal, and after suggesting the guanaco, James Muehlner, a developer of the + project, suggested (randomly): "guacamole".

The name had a nice ring, we weren't embarrassed to use it, and it stuck.

A.2.

What does "clientless" mean?

The term "clientless" means that no specific client is needed. A Guacamole + user needs only have an HTML5 web browser installed, which is exceedingly + common; virtually all modern computers and mobile devices have such a browser + installed by default.

In this sense, Guacamole is "clientless" in that it does not require any + additional software to be installed beyond what is considered standard for any + computer.

A.3.

Does Guacamole use WebSocket?

Guacamole uses either WebSocket or plain HTTP, whichever is supported by both + the browser and your servlet container. If WebSocket cannot be used for any + reason, Guacamole will fall back to using HTTP.

Historically, Guacamole had no WebSocket support at all. This was due to a + lack of browser support and lack of a true standard. Overall, it didn't matter + as there really wasn't any need: the tunnel used by Guacamole when WebSocket is + not available is largely equivalent to WebSocket in terms of efficiency and + latency, and is more compatible with proxies and existing browsers.

A.4.

I have Tomcat (or some other servlet container) set up behind a proxy (like + mod_proxy) and cannot connect to Guacamole. Why? How do I solve this?

You need to enable automatic flushing of the proxy's buffer as it receives + packets.

Most proxies, including mod_proxy, buffer data received from the server, and + will not flush this data in real-time. Each proxy has an option to force + flushing of each packet automatically, as this is necessary for streaming + applications like Guacamole, but this is usually not enabled by default.

Because Guacamole depends on streaming to function, a proxy configured to not + automatically flush packets will disrupt the stream to the point that the + connection seems unreasonably slow, or just fails to establish altogether.

In the case of mod_proxy, this option is flushpackets=on.

A.5.

I connect to the internet through a web proxy, and cannot connect to + Guacamole. I cannot reconfigure the proxy. How do I solve this?

You need to enable automatic flushing of your proxy's buffer to avoid + disrupting the stream used by Guacamole.

If you cannot change the settings of your proxy, using HTTPS instead of HTTP + should solve the problem. Proxies are required to stream HTTPS because of the + nature of SSL. Using HTTPS will allow Guacamole traffic to stream through + proxies unencumbered, even if you cannot access the proxy settings directly.

A.6.

Can I buy special licensing of the Guacamole code base, such that I can use it + in my own product, without providing the source to my users, without + contributing back, and without acknowledging the project?

Usually, no. Previous requests for such licensing have been very one-sided and + there would be no direct or indirect benefit to the community and the project. + That said, we handle requests for licensing on a case-by-case basis. In general, + any special licensing has to somehow provide for the community and the + open-source project.

A.7.

Can I pay for custom Guacamole work, or for help integrating Guacamole into my + product, if the open source nature and licenses are preserved?

Yes. We love to be paid to work on Guacamole, especially if that work remains + open source.

A.8.

How can I contribute to the project?

If you are a programmer and want to contribute code, Guacamole is open-source + and you are welcome to do so! Just send us your patches. There is no guarantee + that your patch will be added to the upstream source, and all changes are + carefully reviewed.

If you are not a programmer, but want to help out, feel free to look through + the documentation or try installing Guacamole and test it out. General editing, + documentation contributions, and testing are always helpful.

A.9.

How can I become an official member of the project?

The short answer is: "by being asked."

People are only added as official members of the Guacamole project after their + work has been proven. This usually means you will have contributed code in the + form of patches before, or we know you from extensive testing work, or you + frequently help with documentation, and we are impressed enough that we want you + as part of the project.

All that said, you do not need to be a member of the project to help out. Feel + free to contribute anything.

A.10.

I think I've found a bug. How do I report it?

The project tracks in-progress tasks and bugs via the JIRA instance hosted by + the Apache Software Foundation:

https://issues.apache.org/jira/browse/GUACAMOLE/

All bugs should be reported there as new issues. This is also where you would + request a new feature. If the bug you found is security-related, we would prefer + to be contacted personally via email, such that the bug can be fixed before + becoming dangerously widely known.

A.11.

I need help! Where can I find some?

If you would like help with Apache Guacamole, or wish to help others, we + highly recommend sending an email to the one of the project’s mailing lists. You will need to subscribe prior to sending + email to any list. All mailing lists are actively filtered for + spam, and any email not originating from a subscriber will bounce.

There are two primary mailing lists:

The user list is intended for general questions and discussions + which do not necessarily pertain to development. This list replaces + the old SourceForge forums used by Guacamole prior to its + acceptance into the Apache Incubator.

If you're not sure which mailing list to use, the user + list is probably the correct choice.

The development list is for development-related discussion + involving people who are contributors to the Apache Guacamole + project (or who wish to become contributors).

+ +
+ + + \ No newline at end of file http://git-wip-us.apache.org/repos/asf/incubator-guacamole-website/blob/2441fd18/doc/0.9.11-incubating/gug/guacamole-architecture.html ---------------------------------------------------------------------- diff --git a/doc/0.9.11-incubating/gug/guacamole-architecture.html b/doc/0.9.11-incubating/gug/guacamole-architecture.html new file mode 100644 index 0000000..a8e42d4 --- /dev/null +++ b/doc/0.9.11-incubating/gug/guacamole-architecture.html @@ -0,0 +1,83 @@ + +Chapter 1. Implementation and architecture + + + + +
+

Chapter 1. Implementation and architecture

Guacamole is not a self-contained web application and is made up of many parts. The web + application is actually intended to be simple and minimal, with the majority of the + gruntwork performed by lower-level components.

Users connect to a Guacamole server with their web browser. The Guacamole client, written + in JavaScript, is served to users by a webserver within the Guacamole server. Once loaded, + this client connects back to the server over HTTP using the Guacamole protocol.

The web application deployed to the Guacamole server reads the Guacamole protocol and + forwards it to guacd, the native Guacamole proxy. This proxy actually interprets the + contents of the Guacamole protocol, connecting to any number of remote desktop servers on + behalf of the user.

The Guacamole protocol combined with guacd provide protocol agnosticism: neither the + Guacamole client nor the web application need to be aware of what remote desktop protocol is + actually being used.

The Guacamole protocol

The web application does not understand any remote desktop protocol at all. It does + not contain support for VNC or RDP or any other protocol supported by the Guacamole + stack. It actually only understands the Guacamole protocol, which is a protocol for + remote display rendering and event transport. While a protocol with those properties + would naturally have the same abilities as a remote desktop protocol, the design + principles behind a remote desktop protocol and the Guacamole protocol are different: + the Guacamole protocol is not intended to implement the features of a specific desktop + environment.

As a remote display and interaction protocol, Guacamole implements a superset of + existing remote desktop protocols. Adding support for a particular remote desktop + protocol (like RDP) to Guacamole thus involves writing a middle layer which "translates" + between the remote desktop protocol and the Guacamole protocol. Implementing such a + translation is no different than implementing any native client, except that this + particular implementation renders to a remote display rather than a local one.

The middle layer that handles this translation is guacd.

guacd

guacd is the heart of Guacamole which dynamically loads support for remote desktop + protocols (called "client plugins") and connects them to remote desktops based on + instructions received from the web application.

guacd is a daemon process which is installed along with Guacamole and runs in the + background, listening for TCP connections from the web application. guacd also does not + understand any specific remote desktop protocol, but rather implements just enough of + the Guacamole protocol to determine which protocol support needs to be loaded and what + arguments must be passed to it. Once a client plugin is loaded, it runs independently of + guacd and has full control of the communication between itself and the web application + until the client plugin terminates.

guacd and all client plugins depend on a common library, libguac, which makes + communication via the Guacamole protocol easier and a bit more abstract.

The web application

The part of Guacamole that a user actually interacts with is the web + application.

The web application, as mentioned before, does not implement any remote desktop + protocol. It relies on guacd, and implements nothing more than a spiffy web interface + and authentication layer.

We chose to implement the server side of the web application in Java, but there's no + reason that it can't be written in a different language. In fact, because Guacamole is + intended be an API, we encourage this.

RealMint

Guacamole is now a generalized remote desktop gateway, but this was not always the + case. Guacamole began as a purely text-based Telnet client written in JavaScript called + RealMint ("RealMint" is an anagram for "terminal"). It was written + mainly as a demonstration and, while intended to be useful, its main claim to fame was + only that it was pure JavaScript.

The tunnel used by RealMint was written in PHP. In contrast to Guacamole's HTTP + tunnel, RealMint's tunnel used only simple long-polling and was inefficient. RealMint + had a decent keyboard implementation which lives on now in parts of Guacamole's keyboard + code, but this was really the extent of RealMint's features and usability.

Given that it was just an implementation of a legacy protocol, and that several other + JavaScript terminal emulators exist, most of which well-established and stable, the + project was dropped.

VNC Client

Once the developers learned of the HTML5 canvas tag, and saw that it was already + implemented in Firefox and Chrome, work started instead on a proof-of-concept JavaScript + VNC client.

This client was purely JavaScript with a Java server component, and worked by + translating VNC into an XML-based version of the same. Its development was naturally + driven by VNC's features, and its scope was limited to forwarding a single connection to + a set of users. Although relatively slow, the proof-of-concept worked well enough that + the project needed an online place to live, and was registered with SourceForge as + "Guacamole" - an HTML5 VNC client.

As Guacamole grew and became more than a proof-of-concept, the need for speed + increased, and the old RealMint-style long polling was dropped, as was the use of + XML.

As WebSocket could not be trusted to be supported at the time, and Java had no + WebSocket standard for servlets, an equivalent HTTP-based tunnel was developed. This + tunnel is still used today if WebSocket cannot be used for any reason.

Remote Desktop Gateway

A faster text-based protocol was developed which could present the features of + multiple remote desktop protocols, not just VNC. The entire system was rearchitected + into a standard daemon, guacd, and a common library, libguac, which drove both the + daemon and protocol support, which became extendable.

The scope of the project expanded from an adequate VNC client to a performant HTML5 + remote desktop gateway and general API. In its current state, Guacamole can be used as a + central gateway to access any number of machines running different remote desktop + servers. It provides extendable authentication, and in the case you need something more + specialized, a general API for HTML5-based remote access.

+ +
+ + + \ No newline at end of file http://git-wip-us.apache.org/repos/asf/incubator-guacamole-website/blob/2441fd18/doc/0.9.11-incubating/gug/guacamole-common-js.html ---------------------------------------------------------------------- diff --git a/doc/0.9.11-incubating/gug/guacamole-common-js.html b/doc/0.9.11-incubating/gug/guacamole-common-js.html new file mode 100644 index 0000000..dd6ae4a --- /dev/null +++ b/doc/0.9.11-incubating/gug/guacamole-common-js.html @@ -0,0 +1,263 @@ + +Chapter 16. guacamole-common-js + + + + +
+

Chapter 16. guacamole-common-js

The Guacamole project provides a JavaScript API for interfacing with + other components that conform to the design of Guacamole, such as + projects using libguac or guacamole-common. This API is called + guacamole-common-js.

guacamole-common-js provides a JavaScript implementation of a + Guacamole client, as well as tunneling mechanisms for getting protocol + data out of JavaScript and into guacd or the server side of a web + application.

For convenience, it also provides mouse and keyboard abstraction objects that translate + JavaScript mouse, touch, and keyboard events into consistent data that Guacamole can more + easily digest. The extendable on-screen keyboard that was developed for the Guacamole web + application is also included.

Guacamole client

The main benefit to using the JavaScript API is the full Guacamole + client implementation, which implements all Guacamole instructions, + and makes use of the tunnel implementations provided by both the + JavaScript and Java APIs.

Using the Guacamole client is straightforward. The client, like + all other objects within the JavaScript API, is within the + Guacamole namespace. It is instantiated given an + existing, unconnected tunnel:

var client = new Guacamole.Client(tunnel);

Once you have the client, it won't immediately appear within the + DOM. You need to add its display element manually:

document.body.appendChild(client.getDisplay().getElement());

At this point, the client will be visible, rendering all updates + as soon as they are received through the tunnel.

client.connect();

It is possible to pass arbitrary data to the tunnel during + connection which can be used for authentication or for choosing a + particular connection. When the connect() + function of the Guacamole client is called, it in turn calls the + connect() function of the tunnel + originally given to the client, establishing a connection.

Important

When creating the Guacamole.Client, the + tunnel used must not already be connected. The + Guacamole.Client will call the + connect() function for you when its + own connect() function is invoked. If + the tunnel is already connected when it is given to the + Guacamole.Client, connection may not + work at all.

In general, all instructions available within the Guacamole + protocol are automatically handled by the Guacamole client, + including instructions related to audio and video. The only + instructions which you must handle yourself are "name" (used to name + the connection), "clipboard" (used to update clipboard data on the + client side), and "error" (used when something goes wrong + server-side). Each of these instructions has a corresponding event + handler; you need only supply functions to handle these events. If + any of these event handlers are left unset, the corresponding + instructions are simply ignored.

HTTP tunnel

Both the Java and JavaScript API implement corresponding ends of + an HTTP tunnel, based on + XMLHttpRequest.

The tunnel is a true stream - there is no polling. An initial + request is made from the JavaScript side, and this request is + handled on the Java side. While this request is open, data is + streamed along the connection, and instructions within this stream + are handled as soon as they are received by the client.

While data is being streamed along this existing connection, a + second connection attempt is made. Data continues to be streamed + along the original connection until the server receives and handles + the second request, at which point the original connection closes + and the stream is transferred to the new connection.

This process repeats, alternating between active streams, thus + creating an unbroken sequence of instructions, while also allowing + JavaScript to free any memory used by the previously active + connection.

The tunnel is created by supplying the relative URL to the + server-side tunnel servlet:

var tunnel = new Guacamole.Tunnel("tunnel");

Once created, the tunnel can be passed to a + Guacamole.Client for use in a Guacamole + connection.

The tunnel actually takes care of the Guacamole protocol parsing + on behalf of the client, triggering "oninstruction" events for every + instruction received, splitting each element into elements of an + array so that the client doesn't have to.

Input abstraction

Browsers can be rather finicky when it comes to keyboard and mouse + input, not to mention touch events. There is little agreement on + which keyboard events get fired when, and what detail about the + event is made available to JavaScript. Touch and mouse events can + also cause confusion, as most browsers will generate + both events when the user touches the + screen (for compatibility with JavaScript code that only handles + mouse events), making it more difficult for applications to support + both mouse and touch independently.

The Guacamole JavaScript API abstracts mouse, keyboard, and touch + interaction, providing several helper objects which act as an + abstract interface between you and the browser events.

Mouse

Mouse event abstraction is provided by the + Guacamole.Mouse object. Given an + arbitrary DOM element, Guacamole.Mouse + triggers onmousedown, + onmousemove, and + onmouseup events which are consistent + across browsers. This object only response. to true mouse + events. Mouse events which are actually the result of touch + events are ignored.

var element = document.getElementById("some-arbitrary-id");
+var mouse = new Guacamole.Mouse(element);
+
+mouse.onmousedown =
+mouse.onmousemove =
+mouse.onmouseup   = function(state) {
+
+    // Do something with the mouse state received ...
+
+};

The handles of each event are given an instance of + Guacamole.Mouse.State which + represents the current state of the mouse, containing the state + of each button (including the scroll wheel) as well as the X and + Y coordinates of the pointer in pixels.

Touch

Touch event abstraction is provided by either + Guacamole.Touchpad (emulates a + touchpad to generate artificial mouse events) or + Guacamole.Touchscreen (emulates a + touchscreen, again generating artificial mouse events). + Guacamole uses the touchpad emulation, as this provides the most + flexibility and mouse-like features, including scrollwheel and + clicking with different buttons, but your preferences may + differ.

var element = document.getElementById("some-arbitrary-id");
+var touch = new Guacamole.Touchpad(element); // or Guacamole.Touchscreen
+
+touch.onmousedown =
+touch.onmousemove =
+touch.onmouseup   = function(state) {
+
+    // Do something with the mouse state received ...
+
+};

Note that even though these objects are touch-specific, they + still provide mouse events. The state object given to the event + handlers of each event is still an instance of + Guacamole.Mouse.State.

Ultimately, you could assign the same event handler to all the + events of both an instance of + Guacamole.Mouse as well as + Guacamole.Touchscreen or + Guacamole.Touchpad, and you would + magically gain mouse and touch support. This support, being + driven by the needs of remote desktop, is naturally geared + around the mouse and providing a reasonable means of interacting + with it. For an actual mouse, events are translated simply and + literally, while touch events go through additional emulation + and heuristics. From the perspective of the user and the code, + this is all transparent.

Keyboard

Keyboard events in Guacamole are abstracted with the + Guacamole.Keyboard object as only + keyup and keydown events; there is no keypress like there is in + JavaScript. Further, all the craziness of keycodes vs. scancodes + vs. key identifiers normally present across browsers is + abstracted away. All your event handlers will see is an X11 + keysym, which represent every key unambiguously. Conveniently, + X11 keysyms are also what the Guacamole protocol requires, so if + you want to use Guacamole.Keyboard to + drive key events sent over the Guacamole protocol, everything + can be connected directly.

Just like the other input abstraction objects, + Guacamole.Keyboard requires a DOM + element as an event target. Only key events directed at this + element will be handled.

var keyboard = new Guacamole.Keyboard(document);
+
+keyboard.onkeydown = function(keysym) {
+    // Do something ...
+};
+
+keyboard.onkeyup = function(keysym) {
+    // Do something ...
+};

In this case, we are using document as + the event target, thus receiving all key events while the + browser window (or tab) has focus.

On-screen keyboard

The Guacamole JavaScript API also provides an extendable on-screen + keyboard, Guacamole.OnScreenKeyboard, which + requires the URL of an XML file describing the keyboard layout. The + on-screen keyboard object provides no hard-coded layout information; + the keyboard layout is described entirely within the XML layout + file.

Keyboard layouts

The keyboard layout XML included in the Guacamole web + application would be a good place to start regarding how these + layout files are written, but in general, the keyboard is simply + a set of rows or columns, denoted with <row> and + <column> tags respectively, where each can + be nested within the other as desired.

Each key is represented with a <key> tag, but + this is not what the user sees, nor what generates the key + event. Each key contains any number of <cap> + tags, which represent the visible part of the key. The cap + describes which X11 keysym will be sent when the key is pressed. + Each cap can be associated with any combination of arbitrary + modifier flags which dictate when that cap is active.

For example:

<keyboard lang="en_US" layout="example" size="5">
+    <row>
+        <key size="4">
+            <cap modifier="shift" keysym="0xFFE1">Shift</cap>
+        </key>
+        <key>
+            <cap>a</cap>
+            <cap if="shift">A</cap>
+        </key>
+    </row>
+</keyboard>

Here we have a very simple keyboard which defines only two + keys: "shift" (a modifier) and the letter "a". When "shift" is + pressed, it sets the "shift" modifier, affecting other keys in + the keyboard. The "a" key has two caps: one lowercase (the + default) and one uppercase (which requires the shift modifier to + be active).

Notice that the shift key needed the keysym explicitly + specified, while the "a" key did not. This is because the + on-screen keyboard will automatically derive the correct keysym + from the text of the key cap if the text contains only a single + character.

Displaying the keyboard

Once you have a keyboard layout available, adding an on-screen + keyboard to your application is simple:

// Add keyboard to body
+var keyboard = new Guacamole.OnScreenKeyboard("path/to/layout.xml");
+document.body.appendChild(keyboard.getElement());
+
+// Set size of keyboard to 100 pixels
+keyboard.resize(100);

Here, we have explicitly specified the width of the keyboard + as 100 pixels. Normally, you would determine this by inspecting + the width of the containing component, or by deciding on a + reasonable width beforehand. Once the width is given, the height + of the keyboard is determined based on the arrangement of each + row.

Styling the keyboard

While the Guacamole.OnScreenKeyboard + object will handle most of the layout, you will still need to + style everything yourself with CSS to get the elements to render + properly and the keys to change state when clicked or activated. + It defines several CSS classes, which you will need to manually + style to get things looking as desired:

guac-keyboard

This class is assigned to the root element + containing the entire keyboard, returned by + getElement(),

guac-keyboard-row

Assigned to the div elements which + contain each row.

guac-keyboard-column

Assigned to the div elements which + contain each column.

guac-keyboard-gap

Assigned to any div elements created + as a result of <gap> tags in the + keyboard layout. <gap> tags are + intended to behave as keys with no visible styling + or caps.

guac-keyboard-key-container

Assigned to the div element which + contains a key, and provides that key with its + required dimensions. It is this element that will be + scaled relative to the size specified in the layout + XML and the size given to the resize() + function.

guac-keyboard-key

Assigned to the div element which + represents the actual key, not the cap. This element + will not directly contain text, but it will contain + all caps that this key can have. With clever CSS + rules, you can take advantage of this and cause + inactive caps to appear on the key in a corner (for + example), or hide them entirely.

guac-keyboard-cap

Assigned to the div element + representing a key cap. Each cap is a child of its + corresponding key, and it is up to the author of the + CSS rules to hide or show or reposition each cap + appropriately. Each cap will contain the display + text defined within the <cap> + element in the layout XML.

guac-keyboard-requires-MODIFIER

Added to the cap element when that cap requires a + specific modifier.

guac-keyboard-uses-MODIFIER

Added to the key element when any cap contained + within it requires a specific modifier.

guac-keyboard-modifier-MODIFIER

Added to and removed from the root keyboard + element when a modifier key is activated or + deactivated respectively.

guac-keyboard-pressed

Added to and removed from any key element as it is + pressed and released respectively.

Important

The CSS rules required for the on-screen keyboard to work + as expected can be quite complex. Looking over the CSS rules + used by the on-screen keyboard in the Guacamole web + application would be a good place to start to see how the + appearance of each key can be driven through the simple + class changes described above.

Inspecting the elements of an active on-screen keyboard + within the Guacamole web application with the developer + tools of your favorite browser is also a good idea.

Handling key events

Key events generated by the on-screen keyboard are identical + to those of Guacamole.Keyboard in that + they consist only of a single X11 keysym. Only keyup and keydown + events exist, as before; there is no keypress event.

// Assuming we have an instance of Guacamole.OnScreenKeyboard already
+// called "keyboard"
+
+keyboard.onkeydown = function(keysym) {
+    // Do something ...
+};
+
+keyboard.onkeyup = function(keysym) {
+    // Do something ...
+};
+ +
+ + + \ No newline at end of file http://git-wip-us.apache.org/repos/asf/incubator-guacamole-website/blob/2441fd18/doc/0.9.11-incubating/gug/guacamole-common.html ---------------------------------------------------------------------- diff --git a/doc/0.9.11-incubating/gug/guacamole-common.html b/doc/0.9.11-incubating/gug/guacamole-common.html new file mode 100644 index 0000000..e325511 --- /dev/null +++ b/doc/0.9.11-incubating/gug/guacamole-common.html @@ -0,0 +1,141 @@ + +Chapter 15. guacamole-common + + + + +
+

Chapter 15. guacamole-common

The Java API provided by the Guacamole project is called guacamole-common. It provides a + basic means of tunneling data between the JavaScript client provided by guacamole-common-js + and the native proxy daemon, guacd, and for dealing with the Guacamole protocol. The purpose + of this library is to facilitate the creation of custom tunnels between the JavaScript + client and guacd, allowing your Guacamole-driven web application to enforce its own security + model, if any, and dictate exactly what connections are established.

HTTP tunnel

The Guacamole Java API implements the HTTP tunnel using a servlet + called GuacamoleHTTPTunnelServlet. This + servlet handles all requests coming to it over HTTP from the + JavaScript client, and translated them into connect, read, or write + requests, which each get dispatched to the + doConnect(), + doRead(), and + doWrite() functions accordingly.

Normally, you wouldn't touch the doRead() + and doWrite() functions, as these have + already been written to properly handle the requests of the + JavaScript tunnel, and if you feel the need to touch these + functions, you are probably better off writing your own tunnel + implementation, although such a thing is difficult to do in a + performant way.

When developing an application based on the Guacamole API, you + should use GuacamoleHTTPTunnelServlet by + extending it, implementing your own version of + doConnect(), which is the only abstract + function it defines. The tutorial later in this book demonstrating + how to write a Guacamole-based web application shows the basics of + doing this, but generally, doConnect() is + an excellent place for authentication or other validation, as it is + the responsibility of doConnect() to create + (or not create) the actual tunnel. If + doConnect() does not create the tunnel, + communication between the JavaScript client and guacd cannot take + place, which is an ideal power to have as an authenticator.

The doConnect() function is expected to return a new + GuacamoleTunnel, but it is completely up to the + implementation to decide how that tunnel is to be created. The already-implemented parts + of GuacamoleHTTPTunnelServlet then return the unique identifier + of this tunnel to the JavaScript client, allowing its own tunnel implementation to + continue to communicate with the tunnel existing on the Java side.

Instances of GuacamoleTunnel are created associated with a + GuacamoleSocket, which is the abstract interface surrounding + the low-level connection to guacd. Overall, there is a socket + (GuacamoleSocket) which provides a TCP connection to guacd. + This socket is exposed to GuacamoleTunnel, which provides + abstract protocol access around what is actually (but secretly, through the abstraction + of the API) a TCP socket.

The Guacamole web application extends this tunnel servlet in order + to implement authentication at the lowest possible level, + effectively prohibiting communication between the client and any + remote desktops unless they have properly authenticated. Your own + implementation can be considerably simpler, especially if you don't + need authentication:

public class MyGuacamoleTunnelServlet
+    extends GuacamoleHTTPTunnelServlet {
+
+    @Override
+    protected GuacamoleTunnel doConnect(HttpServletRequest request)
+        throws GuacamoleException {
+
+        // Connect to guacd here (this is a STUB)
+        GuacamoleSocket socket;
+
+        // Return a new tunnel which uses the connected socket
+        return new SimpleGuacamoleTunnel(socket);
+
+    }
+
+}

Using the Guacamole protocol

guacamole-common provides basic low-level support for the + Guacamole protocol. This low-level support is leveraged by the HTTP + tunnel implementation to satisfy the requirements of the JavaScript + client implementation, as the JavaScript client expects the + handshake procedure to have already taken place. This support exists + through the GuacamoleReader and + GuacamoleWriter classes, which are + similar to Java's Reader and + Writer classes, except that they deal + with the Guacamole protocol specifically, and thus have slightly + different contracts.

GuacamoleReader

GuacamoleReader provides a very basic + read() function which is required + to return one or more complete instructions in a + char array. It also provides the typical + available() function, which informs + you whether read() is likely to block + the next time it is called, and an even more abstract version of + read() called + readInstruction() which returns one + instruction at a time, wrapped within a + GuacamoleInstruction instance.

Normally, you would not need to use this class yourself. It is + used by ConfiguredGuacamoleSocket to + complete the Guacamole protocol handshake procedure, and it is + used by GuacamoleHTTPTunnelServlet within + doRead() to implement the reading + half of the tunnel.

The only concrete implementation of + GuacamoleReader is + ReaderGuacamoleReader, which wraps a + Java Reader, using that as the source for + data to parse into Guacamole instructions. Again, you would not + normally directly use this class, nor instantiate it yourself. A + working, concrete instance of + GuacamoleReader can be retrieved from + any GuacamoleSocket or + GuacamoleTunnel.

GuacamoleWriter

GuacamoleWriter provides a very basic + write() function and a more + abstract version called + writeInstruction() which writes + instances of GuacamoleInstruction. These + functions are analogous to the read() + and readInstruction() functions + provided by GuacamoleReader, and have + similar restrictions: the contract imposed by + write() requires that written + instructions be complete

The only concrete implementation of + GuacamoleWriter is + WriterGuacamoleWriter, which wraps a + Java Writer, using that as the + destination for Guacamole instruction data, but you would not + normally directly use this class, nor instantiate it yourself. + It is used by ConfiguredGuacamoleSocket + to complete the Guacamole protocol handshake procedure, and it + is used by GuacamoleHTTPTunnelServlet + within doWrite() to implement the + writing half of the tunnel.

If necessary, a GuacamoleWriter can be + retrieved from any GuacamoleSocket or + GuacamoleTunnel, but in most cases, + the classes provided by the Guacamole Java API which already use + GuacamoleWriter will be + sufficient.

+ +
+ + + \ No newline at end of file