У интеграторов, наверняка, было тз вида "1. по номеру телефона теперь не проверяем сами, а получаем ответ от внешней системы. 2. Данные пользователя берём не у себя, а от внешней системы", ну и внешняя система, естественно, "чёрный ящик". Сталкивались.
А про правильно - КМК, просто выбор нужного аккаунта из списка аккаунтов, в которых ты клиент или представитель, после входа.
Проблема не в том что его ввели, а в том, что в одной из систем были некоректные данные. В сбере слили две сущности - клиент и представитель клиента, оттуда и коллизия.
С точки зрения сбера всё валидно, номер == клиент. Косяк в том, что номер представителя должен быть отдельным полем. Но, опять же, вопрос не в SSO, а в схеме данных и в редкости такого кейса, как у вас. Я, как и многие, зашёл не за этим.
Скайп при переходе на электрон стал есть в 8-10 раз больше памяти и заметно медленнее работать. Да, появился официальный клиент под линукс, это плюс, но у меня много знакомых ушли из скайпа именно из-за того, как он стал тормозить при наличии хотя-бы десятка чатов 30++ участников.
Вполне логично с точки зрения сбера - интеграция покупаемого в свою экосистему.
Ну, в первую очередь - так себе идея использовать "семейный" телефон для банка. А если не использовать - то и вопрос не стоит.
В контексте статьи - коллизия как раз в случае учетки на номере, отличном от используемого для сберИд.
Данные от внешней системы, по статье, это фио и номер телефона. При валидности обеих записей они идентичны - сливать нечего, конфликты отсутствуют.
А учетки с одинаковым именем - учетки одного человека, т.к. имя - номер телефона. Если обе учетки валидны, опять же.
Исправление невалидности данных в "черном ящике" - вне ЗО интеграторов, обычно.
У интеграторов, наверняка, было тз вида "1. по номеру телефона теперь не проверяем сами, а получаем ответ от внешней системы. 2. Данные пользователя берём не у себя, а от внешней системы", ну и внешняя система, естественно, "чёрный ящик". Сталкивались.
А про правильно - КМК, просто выбор нужного аккаунта из списка аккаунтов, в которых ты клиент или представитель, после входа.
Ответил в ветке выше.
Нет :)
Поле_номер_клиента: <номер клиента> -- правильно.
Поле_номер_клиента: <номер представителя клиента> -- неправильно.
Косяк со стороны сбера, никто не спорит же. Но косяк со стороны архитектора данных, а не со стороны интеграции двух систем.
Проблема не в том что его ввели, а в том, что в одной из систем были некоректные данные. В сбере слили две сущности - клиент и представитель клиента, оттуда и коллизия.
С точки зрения сбера всё валидно, номер == клиент. Косяк в том, что номер представителя должен быть отдельным полем. Но, опять же, вопрос не в SSO, а в схеме данных и в редкости такого кейса, как у вас. Я, как и многие, зашёл не за этим.
Скайп при переходе на электрон стал есть в 8-10 раз больше памяти и заметно медленнее работать. Да, появился официальный клиент под линукс, это плюс, но у меня много знакомых ушли из скайпа именно из-за того, как он стал тормозить при наличии хотя-бы десятка чатов 30++ участников.
Вот даже интересно стало, что за курсы такие, без k8s, как везде?