$evalAsync() does not necessarily guarantee execution within a timer;
the provided function may well execute after the current $digest loop
without control returning to the browser. If we need a timer to ensure
focus() behaves reliably, we should explicitly use one via $timeout.
Additionally reporting whether the affected element receives or loses focus causes trouble if the source of the original value is non-assignable. It also seems like it could cause unexpected side effects if usages of guacFocus expect to separate their intent (assigning a value via the expression watched by guacFocus) from the result of attempting to set/remove focus. If tracking of focus is needed, that would best be served by another directive dedicated solely to tracking.
Commit f92bf9c moved the getClientIdentifier() function to the
GroupListItem class, thus making the function available as
item.getClientIdentifier() within the connection or connection group
templates referenced by an instance of the guacGroupList directive.
This change correctly updated all but the connection group template for
the home screen, which was incorrectly updated to reference the
function as if it were directly on the scope. As such a function
doesn't exist, AngularJS didn't substitute any value, resulting in a
non-functional link.
Checking `timezone != null & !timezone.isEmpty()` will result in a
`NullPointerException` when `timezone` is null, as the `&` ensures
`timezone.isEmpty()` will run in all cases.
Parameter tokens are intended to be interpreted by the connections
stored within LDAP. This was previously done through explicitly using a
TokenFilter and the StandardTokens class, however usage of
StandardTokens is now deprecated and the values of tokens to be applied
are now expected to be received through connect(). Usage of
StandardTokens was removed from LDAP with commit 1210d56, but this is
insufficient. An additional parameter must also be provided to the
SimpleConnection constructor to enable its automatic token handling
behavior.
Internet Explorer 11 interprets the "disabled" attribute on all HTML
elements, even unknown elements like AngularJS directives, disabling any
input fields that end up on the DOM tree within those elements. This
breaks the login form.
The alternative "data-disabled" attribute form supported by AngularJS
allows things to work without interference.
Placing the fade animation on the login dialog (which also handles the
error shake-head animation) results in the dialog fading in each time
the login process changes state. It really should only fade when the
overall login interface initially appears.
IE 11 appears to ignore the `Cache-Control` header on requests despite
RFC 7234 and does not invalidate cache after changes are made to a
resource via PUT/DELETE/POST despite RFC 2616. It _does_ behave
correctly when the `Pragma` header is included.
This behavior is not observed for Chrome/Firefox which both correctly
honor the `Cache-Control` header and correctly invalidate cache after
changes.
While this query is generally functioning as described above for all
supported databases, it is not functioning properly for the
non-recursive variant of the MySQL/MariaDB query. This change corrects
that behavior.
Defining an ABI-compatible version of Connectable at the guacamole-ext
level is problematic as concrete implementations of the interface will
suddenly compile despite having no implementation of connect() at all.
We can instead rely on the web application to ensure binary
compatibility, leaving guacamole-ext to define the interface that new
code should use.
Previous implementations of SimpleConnection did not interpret parameter
tokens automatically. Adding that behavior now could have security
implications for downstream users of the class if parameter values may
unexpectedly contain substrings which would be interpreted as tokens,
particularly if parameter values are built from untrusted input.
While raw, internal access to the GuacamoleConfiguration was originally
present in older versions of SimpleConnection, this access was
undocumented and could result in unexpected behavior if the default
constructor was used, getConfiguration() was overridden, or
setConfiguration() was called.
Including `ngRoute` as a dependency of a module which defines a custom
field type will always result in the following error:
Unknown provider: $rootElementProvider <- $rootElement <- $location <- $route <- $location
This seems to be due to the manner in which the injector is created for
field types. `$rootElementProvider` is not available for injection in
the context of the injector of a custom field. This is generally OK, but
`ngRoute` transitively depends on `$rootElementProvider`. Since
`$rootElementProvider` cannot be injected within the context of a field
type, no field type can depend on ngRoute without causing this error.
Note that extensions can still leverage `ngRoute` (this is already done
by the OpenID support). It just cannot be declared as a dependency of a
module containing a custom field type.
Michael Jumper