close

Filter

loading table of contents...

Release Notes / Version 10.2107

Table Of Contents

UUIDs introduced for Users and Groups

The Content Management Server maintains stable and universally unique identifiers (UUIDs) as specified in RFC 4122 for users and groups. Existing and newly created users and groups get UUIDs in addition to existing numeric IDs. UUIDs are not meant to replace existing IDs, and IDs can be used for all purposes as before. Note, that UUIDs are currently only available on the Content Management Server , and not on live servers.

Upgrade:

The Content Server automatically adds new database table columns for UUIDs when started. This affects both management and live servers.

Note, that it is not possible to start a Content Server of a previous release on the database after the new Content Server has adapted the database tables. You should always make a backup of the Content Server database before upgrading. This is even more important for this change.

The Content Server automatically generates UUIDs for existing and newly created builtin users and groups. Predefined well-known users ("admin", "feeder", "studio", "watchdog", "webserver", "publisher", "workflow", "importer", "replicator") and groups ("administratoren", "system", "system-write", "approver", "chief editor", "editor", "importer", "publisher", "composer-role", "approver-role", "publisher-role") receive fixed UUIDs, that will be the same on all systems. For all other builtin users, the Content Server generates random UUIDs that will differ between installations.

External user provider implementations can import UUIDs from an external system, so that logically identical users and groups can have the same UUIDs on different CMS installations. To this end, the ActiveDirectoryUserProvider and SimpleActiveDirectoryUserProvider use Active Directory's objectGUID attribute as UUIDs for the CMS. Custom user provider implementations can be adapted to assign specific UUIDs to their users and groups as well. By default, the Content Server generates random UUIDs for members of custom user providers, so that there's no requirement to adapt them.

Unified API:

In the Unified API , the following methods have been added for UUID support:

  • Member#getUuid()

  • UserRepository#getMember(UUID)

  • UserRepository#getUser(UUID)

  • UserRepository#getGroup(UUID)

Furthermore, the existing methods #getMember(String) , #getUser(String) , and #getGroup(String) of interface UserRepository can now also be called with a UUID's string representation to lookup a user or group by its UUID.

If the Unified API is connected to a live server or to a server of a previous release, then methods that would return a UUID will return null instead.

The Unified API Developer Manual mentions UUIDs in the new section "The User Repository | UUIDs".

UserProvider API:

The API to implement custom user providers has been extended with new methods for UUID support:

  • UserProvider#getUser(UUID, boolean)

  • UserProvider#getGroup(UUID, boolean)

  • LdapUserProvider#idToUuid(String, Attributes)

  • LdapUserProvider#uuidToId(UUID)

  • LdapObject#getUuid()

cm dump:

  • Extended first line of console output for user and group dump by pattern , uuid: <uuid> (just in case you used this line for parsing in automated processes).

  • You may now pass UUIDs as input arguments not only for contents, but also for users and groups. Either directly or via option -U .

(CMS-16917)

Search Results

Table Of Contents