The protocol associated with a tunnel should be correctly set
regardless of whether the tunnel results from a Connection,
ConnectionGroup, or ActiveConnection.
If the protocol name and parameters are retrieved from Connection-
specific endpoints, then the protocol-specific context needed for
Guacamole instructions like "argv" and "required" will only be
available for Connections (not ConnectionGroups or ActiveConnections).
The modifications add translation file for the webapp and the following extensions:
- guacamole-auth-cas
- guacamole-auth-duo
- guacamole-auth-jdbc
- guacamole-auth-openid
- guacamole-auth-quickconnect
- guacamole-auth-radius
- guacamole-auth-saml
- guacamole-auth-totp
Modify the guac-manifest file of the different translated extensions and place translations in alphabetical order
Previous versions of the SQL Server queries relied on permission for
each object being granted from exactly one location, thus allowing
queries to be narrowed by permission using a simple JOIN. This is no
longer the case, as permissions may be inherited from multiple
locations (groups).
Previous versions of the MySQL queries relied on permission for each
object being granted from exactly one location, thus allowing queries
to be narrowed by permission using a simple JOIN. This is no longer
the case, as permissions may be inherited from multiple locations
(groups).
Previous versions of the PostgreSQL queries relied on permission for
each object being granted from exactly one location, thus allowing
queries to be narrowed by permission using a simple JOIN. This is no
longer the case, as permissions may be inherited from multiple
locations (groups).
The proper database IDs must be populated in the current user's
ModeledUser for other parts of the database extension to work
correctly, including saving of user attributes.
As activeTunnels is a live map which may change while
getActiveConnections() is running, it is possible for an initial call
to activeTunnels.isEmpty() to pass yet for the set of connection
identifiers produced to be empty.
If expected fields are deleted rather than reset to empty, those fields
will not be resubmitted in future requests, resulting in the content of
those requests not accurately representing true client-side login state.
For example, if a user receives an insufficient credentials error due to
their password expiring, failing to provide any new password should
result in at least the following fields:
1. Their original username (part of the initial login attempt)
2. Their original password (part of the initial login attempt)
3. Their new password (empty)
If fields are incorrectly reset to null, those fields will not be
submitted, resulting instead in a request containing only:
1. Their original username (part of the initial login attempt)
2. Their original password (part of the initial login attempt)
which is indistinguishable from a normal login attempt.
By definition, a client error is not an internal error, but an
intentional refusal of the server to handle a malformed or otherwise
invalid request. These should not be handled in the same way as server
errors which unexpectedly block processing of a request and should be
corrected by an administrator.
In the case of GUACAMOLE-1152, client errors should not be ignored even
if failures are explicitly configured as tolerated for the associated
authentication provider.
