IBM Connections: идентификатор пользователя против ключа. Почему для одного пользователя используется несколько идентификаторов соединений? - PullRequest
Новая
       49

IBM Connections: идентификатор пользователя против ключа. Почему для одного пользователя используется несколько идентификаторов соединений?

0 голосов
/ 21 ноября 2018

Когда я смотрю на источник страницы профиля, например https://<connections-host>/profiles/html/profileView.do?userid=98A10FD8-FCC3-5DD7-C125-6A9B0055D8C8, я вижу два вида идентификаторов в источнике страницы: 

profilesData.displayedUser = { 
        key: "7a74e3bf-6cf4-40cd-a593-801275661353",
        dn: "<dn>",
        displayName: "Alice Someone", 
        userid:"98A10FD8-FCC3-5DD7-C125-6A9B0055D8C8", 
        // ...
};

userid кажется обычным GUID для пользователя, этоясно для меня.Но почему у нас есть дополнительный атрибут key?Это также похоже на другой GUID, но в нижнем регистре.

Соединения API

Причина, по которой я спрашиваю: Пользовательский API IBM запрашивает атрибут key, например /profiles/atom/profileEntry.do?key=7a74e3bf-6cf4-40cd-a593-801275661353.Мы также можем позвонить /profiles/atom/profileEntry.do?userid=98A10FD8-FCC3-5DD7-C125-6A9B0055D8C8, хотя это официально не задокументировано.

Может кто-нибудь объяснить, почему у нас два идентификатора?И в чем причина использования key вместо userid здесь?Он не согласен с концепцией идентификатора, чтобы быть уникальным.

1 Ответ

0 голосов
/ 21 ноября 2018

Соединения построены из нескольких разных приложений с разными базами данных (Люди, Блоги, Домашняя страница, ....).Каждая БД имеет свою собственную таблицу пользователей со своими ключами.Вторым идентификатором является идентификатор пользователя, который должен быть одинаковым для всех БД.

В вашем примере ключ относится к peopledb.Это действительно только в приложении профилей.Идентификатор пользователя действителен для всех приложений подключений.

...