Skip to content

Release notes for version 2019.1.1

What's new

Improved security, we have now enabled security on all endponts related to creation of content. The componentPage object has been extended to include a status field that is fully configurable to fit your workflow. We have extended the functionalities in the backend to include three new services.

  1. Account, with this service your editors can signup for accounts and you as administrator can approve which users can create their own content.
  2. Editor, this services enables a streamlined publishing flow suited for edtiors that have a need to publish content quickly from a predefined template.
  3. Overbliq Web, this services enableds you content to be accessible also from the web using the same content structure that is available in the native apps.

The ACL implementation in this release prohibits any user that hasn't been assigned acls to edit an item. Also a user with the editor role will as default only be able to editor the content items he/she has created. The default ACLs will only allow the default admin user to edit all pages with the default template. You need to configure default aclTempaltes for all additional componentPage templates that you will use.

Configuration changes

Application setup

As we change how interservice communication is done we also have changed the default configuration, you shouldn't be affected by this. But if you want to change how the interservice communication is done you change the following values in the configurations. Below is an example in YAML format:

    clientId: interservice
    clientSecret: <clientSecret>
    grantType: client_credentials
    accessTokenUri: 'https://localhost:9080/auth-service/oauth/token'

As we change how the internal communication works within the product we now require that the internal hostname is specificed for each running service package. This means that each liberty instance should have internservice_internal_hostname configured, the default value for this is localhost:9080.

Server setup

On the serverside the following configuration changes are neccesary in environments that will upgrade to 2019.1.1. To get the expected behaviour of the editor-ui you need to change the webContainer parameter in the server.xml file to disable libertys default linefeed filtering. If you deploy the Overbliq Web application we recommend that you add the invokeFlushAfterService parameter to the webcontainer to enable a better webrendering experience.

<webContainer keepSeparatorMultipartFormField="true" invokeFlushAfterService="false"/>

We also recommend that you ensure that your running jvm has set the jvm parameter file.encoding to UTF-8.

Workflow setup

To configure your wanted workflow for statuses you need to setup your valid statuses against content-service and if you deploy the editor-ui application you need to configure which status value should be considered draft and which should be considered pubished for the default view.

    draftStatus: draft
    publishStatus: publish

The example above is the default configuration used in our local environment. This then maps to this default configuration for content-service:

    - status: draft
      defaultValue: true
      enabled: true
    - status: published
      defaultValue: false
      enabled: true

The example above sets the workflow configuration to include a default draft and publish status where draft is the default value that will be set on all objects when they are created. Both examples above is the standard configuration for this release and can be overwritten if needed.

Initial ACL setup

On existing environments it is necessary to create default AclTemplates and ACLs for endpoints to work. First step is to generate base AclTempaltes for the wanted sites, manual example would be:

cd deploy/scripts
cat defaultContent/aclTemplates.json|sed 's/{SITEID}/5cddee16-42c4-45bf-8ce9-7b0022321e2c/g' > aclTemplates.json
curl -X POST -d"@aclTemplates.json" -H 'Authorization: Bearer '$OAUTH_TOKEN -H 'Content-Type: application/json' $OVERBLIQ_HOST'/user-service/v1/acltemplates'

The exameple above assumes a fixed siteid, this will be replaced by a script in later versions. Once the default templates are created you will need to apply the templates to existing content by using this REST api:

curl -H 'Authorization: Bearer '$OAUTH_TOKEN -H 'Content-Type: application/json' $OVERBLIQ_HOST'/user-service/v1/acltemplates/apply/ComponentPage'

At the time of writing you need to use the client credential user with SUPER_ADMIN role to be able to create templates as well as apply them. To fetch the tempalate for the admin users use this endpoint:

curl -X GET  -H 'Authorization: Bearer '$OAUTH_TOKEN -H 'Content-Type: application/json' $OVERBLIQ_HOST'/content-service/v1/componentPages/my'

The above endpoint will return the metadata for the componentpages that the admin has access to edit.

Overbliq Web

In this release we include our Web framework for creating a Web version of your content. Included in the application package is some default templates which we recommend you override by creating your own war package based on the Overbliq Web package. To enable friendly urls you need to configure your environment to first enable the friendly url filter and generator and the configure your friendly url map. In your application-customweb.yml create a key called overbliqweb.friendlyUrland set it to true to enable friendly urls. Next step is to add a url map to map actionTargets to uri maps for each site. See below as a sample how the urlmap can be setup for a small demoweb:

  friendlyUrl: "true"
  - id: "1"
    parentId: ""
    uri: ""
    siteName: "default"
      action: "componentPage"
      target: "53"
  - id: "2"
    parentId: ""
    uri: "nyheter"
    siteName: "default"
      action: "componentPage"
      target: "118"
  - id: "4"
    parentId: ""
    uri: "produkter"
      action: "componentPage"
      target: "470"
  - id: "5"
    parentId: "4"
    uri: "overbliq"
      action: "componentPage"
      target: "549"

The sample above will create an url strucutre for both swedish and english pages. The sample structure above will give url tree for some pages on swedish and a few on english. This is more to show the concept than a complete setup. If locale isn't specified it defaults to swedish locale. The finished url tree will look like this:

/                   -> page with id 53
/nyheter            -> page with id 118
/produkter          -> page with id 470
/produkter/overbliq -> page with id 549
/products           -> page with id 470 and force page locale to english
/products/overbliq  -> page with id 549 and force page locale to english