Как создать пользователя Gerrit LDAP через REST API? - PullRequest
0 голосов
/ 06 ноября 2019

Нам нужно перенести около 800 учетных записей пользователей, интегрированных в LDAP, с Gerrit 2.13.6 (с использованием reviewDB для хранения данных учетной записи) на Gerrit 3.0.2 (с использованием git NoteDB для хранения пользовательских данных). Для этого мы решили использовать REST API Gerrit, так как это казалось самым простым решением для этой задачи.

Мы можем легко получить данные всех 800 учетных записей из Gerrit 2.13.6, но у нас есть проблемы при попытке создатьодна работающая интегрированная в LDAP учетная запись в Gerrit 3.0.2. Мы попытались создать учетную запись (назовем ее Foo Bar, с именем входа в foobar) с помощью метода создания учетной записи Gerrit REST, и она работает нормально, за исключением того, что внешние идентификаторы новой учетной записи выглядят так:

[
  {
    "identity": "username:foobar",
    "trusted": true
  },
  {
    "identity": "mailto:FBar@company.com",
    "email_address": "FBar@company.com",
    "trusted": true,
    "can_delete": true
  }
]

вместо того, как они должны выглядеть ниже, для правильных, существующих, интегрированных в LDAP учетных записей:

[
  {
    "identity": "username:foobar",
    "trusted": true
  },
  {
    "identity": "gerrit:foobar",
    "email_address": "FBar@company.com",
    "trusted": true,
    "can_delete": true
  }
]

Неправильная идентификация выше (mailto: FBar@company.com) не позволяет учетной записи должным образомвойти через LDAP (аутентификация не удалась, невозможно создать новую учетную запись с использованием электронной почты - поэтому он даже не распознает эту учетную запись как учетную запись, которую он должен интегрировать с LDAP).

Что мы уже пробовали:1) методы учетной записи Gerrit REST API - у него нет методов для добавления / обновления внешних идентификаторов, чтобы исправить это2) Подтверждение электронной почты созданного пользователя (так как это выглядит как электронное письмо для подтверждения, но не генерирует фактическое электронное письмо с подтверждением) через API - это ничего не меняет для ошибочной личности3) Создание учетных записей без электронной почты (ошибочная идентификация не создается), а затем добавление предпочтительного электронного письма с флагом «no_confirmation» - это снова создает ошибочную идентификацию4) Удаление внешних идентификаторов - удаление неверного идентификатора лишает нас возможности войти в учетную запись. Удаление обоих удостоверений приводит к тому, что Геррит создает двойную учетную запись при первом входе в систему (поскольку электронная почта теперь стала уникальной)

То, что мы пытались и сделали, - первый ответ из этой темы: Невозможно войти в систему после редактирования адресов электронной почты . Это включает в себя:- Клонирование ветки external-ids из репозитория All-Users- Изменение неверного идентификатора для созданного пользователя- Переименование внешнего файла идентификатора в новый хэш SHA1, который соответствует измененному имени идентификатора. - толкая измененияПосле этого изменения пользователь LDAP может фактически войти в свою учетную запись, созданную в бэкэнде, как обычно.

Но приведенное выше решение очень хакерское и не дружественное к автоматизации. Трудно поверить, что это единственное доступное решение.

Кто-нибудь знает лучшее решение этой проблемы?

...