Блог

В нашем Azure B2C мы разрешаем пользователям регистрироваться, используя электронные письма со смешанным регистром в качестве своих логинов (IssuerAssignedId). Теперь у нас много пользователей (не всех, но многих) с именем типа IssuerAssignedId.Surname@domain.com .

В нашем API у нас есть конечные точки, которые выполняют бизнес-проверку пользователя по заданному электронному письму, и клиенты API предоставляют эти электронные письма в нижнем регистре. Таким образом, вызов Graph API не может найти пользователя при отправке электронной почты, например name.surname@domain.com если на самом деле зарегистрирован B2C IssuerAssignedId — это имя.Surname@domain.com .

Мы используем стандартный синтаксис фильтра:

 await _graphServiceClient.Users
  .Request()
  .Filter($"identities/any(c: c/issuerAssignedId eq '{email}' and c/issuer eq '{issuer}')")
  .Select(e => new { e.DisplayName, e.Id, e.Identities})
  .GetAsync();
 

Проблема в том, что запрос фильтра не позволяет использовать функцию tolower() odata, например

 $"identities/any(c: tolower(c/issuerAssignedId) eq '{email}' and c/issuer eq '{issuer}')"
 

поэтому я не могу нормализовать электронное письмо из лямбда-аргумента. Как я понимаю, odata для Graph B2C имеет некоторые ограничения по сравнению со стандартом.

Каким может быть подход к решению такой проблемы?

Если вы используете Graph API для создания записей пользователей, вы можете назначить версию IssuerAssignedId в нижнем регистре mail или атрибут расширения. Затем вы можете использовать это для поиска в нижнем регистре.

Для существующих данных вы можете ввести значение нижнего регистра в новый столбец с помощью вызова исправления Graph API.