Table of Contents

• Changelog for 8.0.7

Changes in 8.0.7

Summary

• Bugfix - Return correct issuerAssignedId on /me: #12635
• Bugfix - Log unmapped thumbnail errors and always report a sabredav exception: #12663
• Enhancement - Eliminate redundant LDAP read-after-write on create and update: #12618
• Enhancement - Add an opt-in bounded LDAP connection pool: #12660
• Enhancement - Retry LDAP operations against a lagging replica: #12672

Details

• Bugfix - Return correct issuerAssignedId on /me: #12635

  The /graph/v1.0/me endpoint reported the internal user UUID as identities[].issuerAssignedId instead of the issuer-assigned identity (the OIDC sub). The endpoint took a fast path that built the user model from the CS3 user in the request context, which does not carry the external identity, so it fell back to the internal UUID. /me now always resolves the user through the identity backend, which reads the stored external identity and returns the correct value. Group memberships are still only expanded when $expand=memberOf is requested.

  https://github.com/owncloud/ocis/pull/12635

• Bugfix - Log unmapped thumbnail errors and always report a sabredav exception: #12663

  The webdav service logged failures of the thumbnails service at debug level only. Errors which are not a property of the requested file, such as the thumbnails service being unreachable, were therefore invisible at production log levels: a complete preview outage produced HTTP 500 responses without a single log line explaining them. Unmapped errors are now logged at error level, while expected per-file outcomes such as an unsupported file type or a file still being processed stay at debug level. Two of the four thumbnail handlers also logged without the request context, so their messages carried no request id.

  In addition, codesEnum only mapped four status codes, so error responses for all other codes were rendered with an empty <s:exception></s:exception> element. The missing entries for 403, 425 and 429 have been added and any remaining unmapped code now falls back to a generic exception name, so clients always receive a usable exception.

  https://github.com/owncloud/ocis/pull/12663

• Enhancement - Eliminate redundant LDAP read-after-write on create and update: #12618

  The graph LDAP backend no longer re-reads an entry immediately after writing it just to recover the entry ID for the response. When oCIS generates the ID itself (GRAPH_LDAP_SERVER_UUID disabled), the create response is now synthesized from the data already sent to the directory, and update responses are built by folding the applied modifications onto the entry that was read before the write. This avoids a round-trip that, against a replicated directory reached through a proxy, could hit a lagging replica and fail or return stale data.

  When the directory assigns the ID (GRAPH_LDAP_SERVER_UUID enabled), creates keep the existing read-back, since the generated ID cannot otherwise be recovered.

  https://github.com/owncloud/ocis/pull/12618

• Enhancement - Add an opt-in bounded LDAP connection pool: #12660

  The auth-basic, users, groups and graph services can now be switched from a single long-lived reconnecting LDAP connection to a bounded pool of connections, so concurrent requests no longer serialize on one socket. Connections are dialed and bound lazily on checkout, unhealthy connections are discarded and lazily re-dialed rather than eagerly reconnected, and checkout blocks with a configurable timeout once the pool is exhausted.

  Pooling is off by default and fully backwards compatible. Enable it per service via ‘OCIS_LDAP_POOL_ENABLED’ (or the service-specific ‘_LDAP_POOL_ENABLED’ override), and tune it with ‘OCIS_LDAP_POOL_SIZE’ (default 5) and ‘OCIS_LDAP_POOL_CHECKOUT_TIMEOUT’ (default 30s).

  The graph service’s identity backend now shares the same LDAP client implementation used by the reva auth/user/group managers instead of maintaining its own separate reconnecting client.

  https://github.com/owncloud/ocis/pull/12660

• Enhancement - Retry LDAP operations against a lagging replica: #12672

  The graph LDAP backend can now retry operations against a replicated directory where a write to the primary is followed by a read that lands on a replica which has not yet caught up. This covers the read-back that recovers a directory-assigned ID after a create (GRAPH_LDAP_SERVER_UUID enabled), which is retried until the entry becomes visible. The retry count and backoff are tunable through GRAPH_LDAP_RETRY_MAX_COUNT, GRAPH_LDAP_RETRY_BASE_DELAY and GRAPH_LDAP_RETRY_MAX_DELAY; the defaults keep the previous behaviour (a single immediate retry with no delay), so existing deployments are unaffected.

  Retries now distinguish reads from writes: a write is no longer retried on a network error, which can surface after the request was already sent and would otherwise apply the mutation twice.

  https://github.com/owncloud/ocis/pull/12672