When retrieving a contextual field like "passphrase", which does not
have a typed representation different from "password" or "hidden", the
contexts where the field's identity is truly known should be preferred
("password" field of a record with a "keypair" field, which MUST be the
key passphrase). When venturing outside well-known contexts, custom
fields should be preferred when their standard counterparts would
already have well-established meanings that differ from the requested
secret (again: "password" of a record with "keypair").
If this is not done, things like retrieving the private key from a
"Login" record fail, as one of the possible storage mechanisms for a
private key is a hidden or password field, which pulls the user's
password instead of their key. In this case, the correct behavior is
to pull the typed value ("keypair") if available, and use custom fields
ONLY otherwise, as those fields have labels that can establish context.
In no other case would it be reliable to assume that a hidden/password
field actually contains a private key.
Doing otherwise would mean that a particular user would never be able
to be associated with a specific password/key by their username if they
have any explicit server-specific account.
Simply calling getPassword() does not currently work correctly, as the
implementation of getPassword() assumes there will be at least one
value if the field is present. This results in an
ArrayIndexOutOfBoundsException for records with empty passwords:
java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
at java.util.ArrayList.rangeCheck(ArrayList.java:659)
at java.util.ArrayList.get(ArrayList.java:435)
at com.keepersecurity.secretsManager.core.KeeperRecord.getPassword(SecretsManager.kt:134)
...
In the event that a secret name is structured, such as the URL-like
notation used by Keeper Secrets Manager, canonicalizing/encoding the
entire name could result in the name itself becoming invalid. Only the
portions that come from tokens should be canonicalized.
The "GUAC_USERNAME" token provided by the webapp is based off the
username provided by the user when they authenticated. The username
token provided by the vault extensions uses the username stored with
the user's corresponding object, which may not be the same.
From https://github.com/apache/guacamole-client/pull/336#discussion_r241549475:
>
> SLF4J formerly recommended that instance variables be used
> (non-static), but no longer takes either stance:
> https://www.slf4j.org/faq.html#declared_static
>
> If we have to pick something to be the standard going forward, I'd
> say let's stick with the accepted idiom of `private static final`
> loggers, with the exception being where it's actually necessary to
> not be `static` (dependency injection).
>
The SSO provider list unexpectedly shrinks when the invalid login
"shake" animation plays due to the use of "display: table-row" vs. the
login form's own use of "display: table-cell". Migrating the SSO
provider list to a simple absolutely-positioned div corrects this and
matches the way the Guacamole version is rendered.
The function supplying the default value may throw a GuacamoleException,
thus the function providing that default should only be invoked when
actually necessary.
The CSS rule expanding the guac-tiled-clients directive to fit the
viewport was not properly updated when the elements and classes involved
were changed via c9900434c4. The
"tiled-client-list" class was previously used to represent the root
element of the set of tiled clients, but that element was replaced with
the "guac-tiled-clients" directive.
The sort order of connection history entries should be descending, with
the most recent connection attempt shown first. This has been incorrect
since 1.3.0 due to the migration to the newer, searchable/sortable
history structure.
Some platforms like ChromeOS use the Meta key as an alternative method
for typing individual keys like Home (Meta+Left) and End (Meta+Right).
In these cases, Meta does not function as a modifier and is actually
implicitly released once the keyboard shortcut is identified.
Since we cannot know whether Meta is actually Meta until it's confirmed
to be used by itself or with another key, we need to defer handling of
Meta keydown until either (1) Meta is released without having been used
with another key or (2) Meta is used as a modifier with another key.
The correct key for the "Windows" key (or the Mac "Command" key) is
"Meta". The "Super" key is an entirely different key not used for that
purpose, and it only currently works with Guacamole because the
Guacamole's base RDP keymap specifically maps the "Super" keys to the
"Windows" keys.
Michael Jumper