App Suite Releases
  • 8.35
  • 7.10.6
Imprint
  • 8.35
  • 7.10.6
Imprint
  • Release 8.38
  • Release 8.37
  • Release 8.36
  • Release 8.35
  • Release 8.34
    • Noteworthy Changes
      • Important Changes
      • App Suite DocumentConverter
      • App Suite Middleware
    • Changelogs
      • App Suite UI
      • App Suite Middleware
      • Additional Components
        • AI Service
        • App Suite DocumentConverter
        • Switchboard
    • Helm Charts
      • App Suite Stack Chart
      • Cache Service
      • DocumentConverter
      • ImageConverter
      • App Suite Middleware Core
      • SpellCheck
      • Switchboard
  • Release 8.33
  • Release 8.32
  • Release 8.31
  • Release 8.30
  • Release 8.29
  • Release 8.28
  • Release 8.27
  • Release 8.26
  • Release 8.25
  • Release 8.24
  • Release 8.23
  • Release 8.22
  • Release 8.21
  • Release 8.20
  • Release 8.19
  • Release 8.18
  • Release 8.17
  • Release 8.16
  • Release 8.15
  • Release 8.14
  • Release 8.13
  • Release 8.12
  • Release 8.11
  • Release 8.10

App Suite Middleware

API - HTTP-API

SCR-1489

Summary: New additional folder field 'com.openexchange.carddav.url' (id 3221)

The "detailed folder data" model of the HTTP API is extended by the additional folder field com.openexchange.carddav.url with column id 3221. The read only field is available for address book folders that are synchronizable via CardDAV, and points to the actual collection's endpoint as used by CardDAV clients.

See the documentation for further details.

API - Java

SCR-1496

Summary: Enhanced OAuthAuthorizationService#validateAccessToken with Header collection parameter

The method com.openexchange.oauth.provider.authorizationserver.spi.OAuthAuthorizationService#validateAccessToken is enhanced with the additional parameter com.openexchange.servlet.Headers holding the headers of the underlying HTTP servlet request that is used to trigger the authentication request.

A default implementation of the new method overload is added, which delegates to the existing method passing the extracted access tokens only.

Behavioral Changes

SCR-1490

Summary: Change of Key Format used for Redis Cache

For the Redis instance dedicated to caching purposes, operation mode Cluster may be used to scale out the Redis service horizontally. Doing so, the keyspace of the stored data is distributed evenly among the available Redis nodes. Technically, every master node in the cluster is responsible for certain hash slots. These slots are the underlying unit of sharding and calculated dynamically from the targeted key(s). Based on that, a command is routed based on its key's hash slot to the corresponding Redis node. If more than one node is targeted by a single command (e.g. DEL or MGET), single commands are executed in a fork/join manner against the correct Redis nodes automatically.

In order to prevent commands targeting multiple keys being distributed among multiple nodes, most of the cache keys that are actually associated with a certain OX context are changed so that the context identifier becomes the designated part of the key where the hash slot is calculated for, by surrounding it with curly braces (\{ and \}). For example, a typical key used to cache user data changes from ox-cache:usr:v1:5:12 to ox-cache:usr:v1:\{5\}:12

Due to this change, existing cached values using the previous key format will no longer be used when a rolling upgrade is performed, and will evict eventually (after com.openexchange.cache.v2.defaultExpirationSeconds, one hour by default). During this period, an increased memory usage will be noticeable after the middleware containers were updated. Therefore it is important that Redis is configured with an appropriate max-memory policy, especially if there's not much headroom left regarding the available usage. Alternatively, one can also flush all cached data once after the upgrade (using the FLUSHALL or FLUSHDB command manually).

SCR-1487

Summary: Health Check extended by Redis Cache

The health check of core middleware is extended with an check named redis.cache for the Redis connector attached to the instance used for caching purposes. It automatically becomes enabled once a Redis cache instance is configured via com.openexchange.redis.cache.enabled=true, and performs an operational check via PING command when called.

Like other checks, it can explicitly be disabled by including redis.cache in the value of property com.openexchange.health.skip. Or, to enable it, but not account its status to the overall result, it can be added to com.openexchange.health.ignore.

See the documentation for further details.

Changed defaults

SCR-1495

Summary: Disable Global Folder Cache by Default

Whether the so called "global folder cache" is enabled or not can be controlled via property com.openexchange.folderstorage.cache.enableGlobalFolderCache.

To avoid redundancies with the low-level database folder cache, its default value will change from true to false.

The absence of the additional caching layer will lower the memory requirements, as well as reduce the number of issued commands towards the Redis cache pod(s). However, since raw folder data is now always post-processed dynamically, this may lead to a slightly increased load on the middleware pods depending on client access patterns.

Configuration

SCR-1488

Summary: New Property com.openexchange.carddav.url

In order to display the CardDAV endpoint of address book collections to users in App Suite, a new lean configuration property named com.openexchange.carddav.url is introduced. Through this property, a URL template can be specified using the variables [hostname] and [folderId].

The property can be defined through the config-cascade and is reloadable. It defaults to https://[hostname]/carddav/[folderId].

See the property documentation for further details.

SCR-1486

Summary: New property 'com.openexchange.carddav.addressbookMultigetLimit'

The lean configuration property com.openexchange.carddav.addressbookMultigetLimit is introduced to configure the maximum number of elements included in CARDDAV:addressbook-multiget responses to the client.

If data from more elements was requested, HTTP/1.1 507 Insufficient Storage responses will get inserted. It defaults to 1000, a value of -1 disabled the limit. Property is reloadable and can be defined through the config-cascade.

Database

SCR-1468

Summary: Add table for webauthn data

In order to implement webauthn for multifactor and authentication, a database table needs to be created to store the public key, signature count, and additional relevant data about the authenticator.

Create a table within the oxdatabase shards:

CREATE TABLE web_authn
    `cid` int(11) DEFAULT NULL,
    `id` int(11) DEFAULT NULL,
    `deviceId` varchar(100) NOT NULL,
    `keyId` varchar(500) NOT NULL,
    `userId` varchar(100) DEFAULT NULL,
    `name` varchar(100) DEFAULT NULL,
    `login` varchar(100) DEFAULT NULL,
    `publicKey` varchar(1000) DEFAULT NULL,
    `attestation` varchar(10000) DEFAULT NULL,
    `clientData` varchar(2000) DEFAULT NULL,
    `counter` int(11) DEFAULT NULL,
    `compromised` bit(1) DEFAULT NULL,
    `isMultifactor` bit(1) DEFAULT NULL,
    `discoverable` bit(1) DEFAULT NULL,
    `lastUsed` datetime DEFAULT NULL,
    `enabled` bit(1) DEFAULT NULL,
    PRIMARY KEY (cid,id,deviceId),
    KEY `web_authn_id_IDX` (`cid`) USING BTREE
    ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;

Packaging/Bundles

SCR-1491

Summary: Bundle to allow new MFA registrations using WebAuthn instead of U2F

Added new bundle com.openexchange.webauthn to allow new MFA registrations using WebAuthn instead of U2F. Also already providing code to implement webauthn as a "full" authentication service. The new bundle has been added to open-xchange-multifactor package.

App Suite DocumentConverter