Upgrading to this version
In apps created with prior versions of Fusion App Studio, you can Upgrade Appkit in Existing Apps.Upgrade Appkit in Existing Apps
Upgrade Appkit in Existing Apps
When you create an Appkit webapp, it uses a specific version of Appkit. Appkit releases occur independently of App Studio releases.You can upgrade web apps to use the latest version of Appkit.How to upgrade
- Stop the app.
-
In the
package.jsonfile at the root of your project, update theappkit-uidependency to the latest Appkit version, for example: -
In the
pom.xmlfile at the root of your project, update the value of theparent.versionproperty to the latest Appkit version, for example: - Upgrade the Appkit Social module, if required.
- Perform any additional upgrade steps that are required for a specific Appkit upgrade. See the Appkit Release Notes for more information.
- Start the app.
Also see the additional required and recommended upgrade steps described in the Release Notes for Appkit 4.4.0 and Appkit 4.3.0.
New features
No new features are included in this release.Improvements
Role-based authorization now supports multiple roles
Appkit now supports role-based authorization with multiple roles. Previously, it was possible to define only a single, global role-based authorization filter.Create authorization filters
Create multiple configuration files for role-based access in thesecurity/access folder. Each file defines a single authorization filter. When Appkit considers whether a specific user can access a specific resource, Appkit evaluates all of the filters.
A best practice is to create authorization filters that do not overlap, that is, that do not refer to the same resources.
Properties
| Property | Required | Notes |
|---|---|---|
allow | optional | Comma-separated list of roles that allow access to a resource |
deny | optional | Comma-separated list of roles that deny access to a resource |
pattern | required | Bar-separated list of paths to which this role-based authorization filter applies |
allow or a deny property. You can supply both, though that is not necessary, because roles that are not allowed are denied. If you do supply both properties and a role is mentioned in both allow and deny, then deny wins.
Example
In this example, users with the rolesEMPLOYEES or CONTRACTORS can access the resources specified in the pattern property, whereas users with the role INTERNS cannot access the resources.
If authorization filters overlap
Although multiple authorization filters can overlap (reference the same resources in thepattern), this is not a good practice.
Appkit figures out and applies the most restrictive filter, but results might be counterintuitive. For example, filter 1 might allow users with the role CONTRACTOR access to a specific resource, whereas filter 4 denies contractors access to the same resource. Filter 4 wins, but you wouldn’t see that if you were looking at filter 1.
Timezone handling
UI components and Appkit server components have been improved to ensure that they handle time zones consistently. Previously, some UI components were aware of local time zones and others were not (instead working with UTC times). The result was that some UI components displayed incorrect times. Improvements are:-
In the
<search:field>tag, you can now specify atimezoneparameter, which tells Appkit the timezone to use when formatting date fields in responses. For example:Use these time zone abbreviations. -
Every HTTP request to Appkit’s API services includes an
X-Client-Timezoneheader, which specifies the browser client’s current timezone as a UTC offset.
Fusion security provider stores JWT to authorize requests to Fusion
Applications that use the Fusion security provider (twigkit.security.provider.fusion) can now check whether an incoming request has a JSON web token (JWT) associated with it (in an Authorization header that begins with Bearer). Appkit extracts the JWT from the header and stores the JWT so that subsequent requests can use the JWT to authorize the requests to Fusion.
The JWT support added in Release 4.5.0 is in addition to the support that was present in prior Appkit releases for pre-authentication with the Fusion security provider.
Now, instead of just checking for a fusion-user-name header in the incoming request, Appkit also checks for a JWT header, if it does not find the fusion-user-name header.
If a JWT is present, Appkit uses the token to authenticate the user. This is typically used when an application (e.g. App Insights) is running behind a Fusion proxy.
After Appkit retrieves and stores the JWT, Appkit can retrieve the JWT to authorize requests to Fusion. By default, Appkit, handles all of this for you.
Explicit configuration
The means by which a user can authorize a request to Fusion can be made explicit by adding anauth: auto | serviceaccount | jwt | native property to the app’s Fusion services resources under resources/services/api/fusion.conf. The default value of this property is native, which means that Appkit uses the pre-authentication provided by the Fusion security provider.
If you use the auto value of the auth property, then Appkit works its way through serviceaccount, jwt, and finally native. With the serviceaccount option, Appkit tries to find a userName and password in resources/services/api/fusion.conf. With the jwt option, Appkit tries to generate a JWT for the user. (This is not the same as the JWT passthrough.)
Geo-filtering and sorting is supported for Elastic 5
In Appkit 4.4.0, support for geo-filtering and sorting was added to the Elasticsearch search platform. The support in Appkit 4.4.0 was solely for Elastic 6. In AppKit 4.5.0, geo-filtering and sorting support has been extended to include Elastic 5.Accessibility is improved for assistive technologies
Appkit’s Angular JS now incorporates ngAria, which improves accessibility by including ARIA attributes in the HTML of Appkit UI components. ARIA attributes help assistive technologies such as screen readers to convey state and semantic information to users.Bug Fixes
-
Hierarchical facets. Hierarchical facet requests now always return hierarchical facets. Previously, a
<search:facet-list>request with multiple hierarchical facets would sometimes return a flattened structure (parent only) for some of the facets. -
dateFormat and time zone. The
dateFormatfilter now applies thetimezoneparameter correctly to both date-time values in a date-time range. -
Responses from multiple suggesters. When there are multiple suggesters, the
<query:suggestions>element now includes responses from all suggesters in their respective sections. Previously, only the responses of one suggester were included.