guacamole-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Jumper (JIRA)" <>
Subject [jira] [Commented] (GUACAMOLE-256) Deprecate the NoAuth extension
Date Mon, 27 Mar 2017 03:55:41 GMT


Michael Jumper commented on GUACAMOLE-256:

I am modifying NoAuth to log a warning like the following:

WARN  o.a.g.a.n.NoAuthenticationProvider - The "NoAuth" extension is \*\*DEPRECATED**! This
extension will be removed from the Guacamole codebase entirely in a future release. Please
consider writing an extension using Guacamole's extension API instead.

as well as marking the class itself as {{@Deprecated}}.

> Deprecate the NoAuth extension
> ------------------------------
>                 Key: GUACAMOLE-256
>                 URL:
>             Project: Guacamole
>          Issue Type: Improvement
>          Components: Documentation, guacamole-auth-noauth
>            Reporter: Michael Jumper
>            Assignee: Michael Jumper
>            Priority: Critical
> The NoAuth extension has been a consistent source of issues for both users and the Guacamole
development community. It's main downstream use has proven to be a quick-and-dirty hack for
integrating Guacamole into an external application, disabling the authentication system rather
than writing an extension to truly integrate the systems together. Over the years, simply
using NoAuth has become bad practice.
> The general thought process surrounding a NoAuth use case tends to be as follows:
> # I wish to integrate Guacamole into my application.
> # My application prompts the user for their username and password.
> # If I link to Guacamole within my application, users will be prompted for their username
and password again.
> # Things would be so much easier if Guacamole didn't prompt for username/password at
> # I will disable Guacamole's authentication system.
> This logic is flawed. If an external application validates a user's username and password,
and that application will link to Guacamole, that doesn't mean that Guacamole is protected
by that username and password. As long as the systems are independent, "disabling" Guacamole's
authentication ensures that part of the deployment is completely unprotected.
> If Guacamole is to be integrated within an external application, then the systems must
be linked such that the user's access is verified at all levels, including within Guacamole.
There is simply no way around this.
> It's time NoAuth was removed as an officially-supported option. Downstream integrations
of Guacamole should use the extension API, as intended by design, or the core Guacamole API
for absolute low-level control.

This message was sent by Atlassian JIRA

View raw message