Legacy Product

Fusion 5.10
    Fusion 5.10

    Appkit SDK 4.5.0 Release Notes

    Release date: 19 August 2019

    Upgrading to this version

    In apps created with prior versions of Fusion App Studio, you can upgrade the Appkit version to 4.5.0.

    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 the security/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.

    You must give users access to resources explicitly by referencing one or more of their roles. A user who has none of the roles mentioned in the authorization-filter files cannot access any resources.

    If a user has multiple roles that specify different access to a resource, then the rule that denies access wins.

    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

    You must supply either an 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 roles EMPLOYEES or CONTRACTORS can access the resources specified in the pattern property, whereas users with the role INTERNS cannot access the resources.

    allow: EMPLOYEES,CONTRACTORS
deny: INTERNS
pattern: (/twigkit/api)|(/dashboard/*)

    If authorization filters overlap

    Although multiple authorization filters can overlap (reference the same resources in the pattern), 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 a timezone parameter, which tells Appkit the timezone to use when formatting date fields in responses. For example:

      <search:field name="date" styling="label-left" label="Created Date" date-format="dd/MM/yy hh:mm" timezone="PST"></search:field>

      Use these time zone abbreviations.

    • Every HTTP request to Appkit’s API services includes an X-Client-Timezone header, 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 an auth: 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 dateFormat filter now applies the timezone parameter 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.