Комментарии 64
В эту же копилку. Для ипотеки мне нужно было открыть эскроу счет в Сбере. Лет 5-6 назад был их клиентом и имел карту, сейчас же нет ничего - ни карт, ни приложения, ни личного кабинета.
Раньше для открытия такого счета было достаточно зайти в офис банка с паспортом и потратить 15 минут времени.
Сейчас:
Прийти в офис
Обновить личные данные (они устарели)
Выслушать все вариации доступных карт
Оформить карту
Установить личный кабинет на свой айфон через их учетку айклауда
Зайти в личный кабинет и подписать наконец документы.
Охъ... жесть какая...
А послать на три буквы копро-менеджера и подписать документы на бумаге своей рукой теперь уж нельзя? Просто очень хочется оценить уровень деградации Сберкассы...
Кстати интересно, а если вообще не иметь телефона, как такой сценарий должен выглядеть? :-/ Между 4 и 5 шагом добавится шаг "Купите телефон и оформите сим карту"? :-/
SSO совершенно непричём, вы сами дали свой номер "левому" человеку для привязки его аккаунта. Если при этом номер был подтверждён, например кодом из СМС, то виноваты вы. Если его просто привязали без всякого подтверждения (сомнительно), то просчёт Сбера.
Во-первых не левому. Во-вторых не давал, а регистрировал человека по генеральной доверенности.
С точки зрения сбера всё валидно, номер == клиент. Косяк в том, что номер представителя должен быть отдельным полем. Но, опять же, вопрос не в SSO, а в схеме данных и в редкости такого кейса, как у вас. Я, как и многие, зашёл не за этим.
Все было валидно пока они две разных учётки не слили в одну :)
Нет :)
Поле_номер_клиента: <номер клиента> -- правильно.
Поле_номер_клиента: <номер представителя клиента> -- неправильно.
Косяк со стороны сбера, никто не спорит же. Но косяк со стороны архитектора данных, а не со стороны интеграции двух систем.
Но косяк со стороны архитектора данных, а не со стороны интеграции двух систем.
Нет, косяк интеграции. В смысле - что ее вообще в таком виде сделали. Потому что в процессе должны были сказать "у нас архитектура данных приведет к накладкам, поэтому таким образом сливать не надо"
И, кстати, можно ответ на мой вопрос ниже - а как правильно надо было?
У интеграторов, наверняка, было тз вида "1. по номеру телефона теперь не проверяем сами, а получаем ответ от внешней системы. 2. Данные пользователя берём не у себя, а от внешней системы", ну и внешняя система, естественно, "чёрный ящик". Сталкивались.
А про правильно - КМК, просто выбор нужного аккаунта из списка аккаунтов, в которых ты клиент или представитель, после входа.
Подпишусь под каждым словом
2. Данные пользователя берём не у себя, а от внешней системы"
Вывод - косяк интеграции и интеграторов. Потому что "а наши данные перенести в эту внешнюю систему?" И как-то слить? А разрешить конфликты? Почему вы, вообще, решили, что учетка с именем 1234567890 у нас и с тем же именем у вас - это учетка одного и того же человека?
Следствие порочной практики идентифицировать человека по номеру телефона...
Данные от внешней системы, по статье, это фио и номер телефона. При валидности обеих записей они идентичны - сливать нечего, конфликты отсутствуют.
А учетки с одинаковым именем - учетки одного человека, т.к. имя - номер телефона. Если обе учетки валидны, опять же.
Исправление невалидности данных в "черном ящике" - вне ЗО интеграторов, обычно.
ФИО, номер телефона и дата рождения (по крайней мере это те данные что я вижу подменённые). Возможно еще что-то.
А учетки с одинаковым именем - учетки одного человека, т.к. имя - номер телефона. Если обе учетки валидны, опять же.
Да с чего бы? Номер/имя учетке в магазине - означает, во многих случаях, всего лишь, что его можно использовать для входа в сайт. Вон, на тумбочке такой валяется - "семейный", которым все члены семьи для покупок используют. Тут оно вообще даже не "человека".
И сливать такую учетку с учеткой банка ну так себе идея.
Ну, в первую очередь - так себе идея использовать "семейный" телефон для банка. А если не использовать - то и вопрос не стоит.
В контексте статьи - коллизия как раз в случае учетки на номере, отличном от используемого для сберИд.
В статье как раз учетка на номере используемом для сбер ID. Просто учетка СберID и учетка с которой её объединили - это разные по смыслу учётки разных людей. Суть истории в том, что эффективные менеджеры решили "все же пользуются сбербанком" и не стали думать что могут быть иные сценарии.
А самое неприятное, что если бы на этом номере не было бы учетки в сбере - то по сути для пользования аптекой создаётся учётная запись в банке. Это уже совсем больная тема на мой вкус...
Ну, в первую очередь - так себе идея использовать "семейный" телефон для банка. А если не использовать - то и вопрос не стоит.
Разумеется, его никто и не использует. Но вопрос стоит. Залогинится я в банк. Или что там еще SberID исползует. Потом пошел на сайт магазина. Сработало SSO. И я оказался в учетке с тем именем, которая мне ну совершенно не нужна и мне надо перелогиниваться, чтобы попасть в ту, с которой я обычно покупки делаю.
В статье, конечно, ситуация другая, но пример показывает, что само по себе SSO - мешать может. И имеет смысл учетки для разных сервисов так и оставлять отдельными.
Неудобно, но плата за использование нескольких учёток одного ССО. У меня с гуглем, яндексом и другими так, ну а что поделаешь?
(Кроме нескольких юзеров в браузере :) )
Неудобно, но плата за использование нескольких учёток одного ССО.
Так вопрос как про то, почему это SSO и несколько учеток понадобилось принудительно делать. Ну работало бы все как работало. А кому плюшек хочется - можно было бы отдельно попросить "разреши, чтобы авторизация вон того сервиса тоже действовала".
Как у кучи сайтов есть свои учетные записи, куда можно попасть как через локальные артефакты доступа, так и через учетку гугла, если слинкуешь.
Или даже у самого Сбербанка yoomoney есть. Куда можно их родной локальной учеткой, SberID-ом, VK ID-ом, госулугами. И ничего, все отлично живет.
Ну кстати у гугла как раз SSO очень неплохо сделано. Он предлагает выбрать учётку, которую использовать при логине через него.
Заголовок не соответствует статье. SSO вообще не об этом. Так и пишите - в Сбере проблемы с их авторизацией/профилями, не водите людей в заблуждение по поводу того, что их ждёт в статье.
SSO в данном случае при чём. Смысл в том, что если его тащить во все сервисы бездумно - могут быть неожиданные коллизии.
Не может быть коллизий, если всё правильно сделано. Номера телефонов/мэйлы должны быть авторизованы. Указал номер телефона? Будь добр код из смс. Нет? И опять же, это вообще не про SSO!
Есть две системы. Есть два различных пользователя. В рамках каждой системы данные пользователь + номер валидны. Но при введении SSO в двух системах получаем коллизию. Почему в данной схеме SSO не при чём?
Это прикол такой? В двух разных системах при использовании SSO должны быть одни и те же данные, так как используется один источник данных. Это аксиома! Если у Сбер во время объединения двух разных баз случилось, что:
а) они в одной базе не проверяли валидность телефонов/мэйлов/ещё чего-то
б) после объединения случились коллизии
то это полностью косяк Сбера, но никак не принципов SSO.
В двух разных системах при использовании SSO должны быть одни и те же данные, так как используется один источник данных.
Статья как бы про то, что не надо было вводить SSO. Ничего бы страшного не случилось, если бы это и дальше были две разные учетки.
А проблема возникла от того, что его ввели.
Так речь именно об этом. Не о том что SSO плохо само по себе. А о том, что его внедряют бездумно :)
Это не Сбер "криво" слил. Это сама идея соединять данные банковских счетов и аптечных или скажем продуктовых заказов бредовая. Продукты / пиццу / суши / нерецептурные лекарства могут заказывать на один аккаунт в семье, а счета у всех быть свои. И наоборот, счета бывают общие на семью, а заказы косметики у жены идти отдельно.
Почему в данной схеме SSO не при чём?
Потому, что объединение учетных записей было сделано по неправильному ключу. Это проблема не SSO, а исключительно в квалификации и добросовестности того, того проектировал и внедрял SSO в соединяемых сервисах. "Убивает не оружие, убивают придурки с автоматами - как вон те двое" (c)
Не может быть коллизий, если всё правильно сделано.
Если.
SSO вообще не об этом.
Об этом. Они слили два разных профиля, в разных сервисах с разными данными в один исключительно по совпадению одного признака. Привычка при покупке сервиса так делать, страшно раздражает - этим вообще все подряд занимаются, не только Сбербанк.
SSO для меня, как C++ника, означает "small string optimization". Всё-таки хорошо бы в начале статьи хотя бы вкратце описывать, что имеется ввиду.
Тащите все в SSO. Аунтификацией должны заниматься специализированные под это сервисы. А то, что кто то сделал слияние сервисов через Ж, никак ни подход, ни технологии под капотом не дискредитируют.
И да, заголовок статьи вводит в заблуждение. Когда пишут «SSO» на тех. ресурсе, о сбере я подумаю в последнюю очередь.
Сбер тут как пример из того, что мне попалось на днях буквально. Проблема может быть у кого угодно если SSO внедрять бездумно / не просчитав возможные пользовательские сценарии.
Тащите все в SSO. Аунтификацией должны заниматься специализированные под это сервисы.
Специализированные сервисы не равно SSO. Можно на одном сервисе авторизировать username@sberbank и username@eapteka. И никак эти учетки не смешивать. И поэтому оно SSO не будет (в каждый сайт надо логинится отдельно, хоть и через один и тот же сервис).
то, что кто то сделал слияние сервисов через Ж
А вот, кстати, как в данном случае сделать правильно? Чтобы желаемое SSO осталось? Т.е. логинимся в Сбербанк (используя юзернейм-он-же-номер-телефона 1234567890) , переходим на сайт Еаптек-и и... в какую учетку попадаем?
Я знаю случаи, когда людям с разными ФИО, но картами одного банка..и сделавшим покупки в плюс-минус одно время - приходили чужие электронные чеки)) И это "особенность системы", и не зависит от банка.
минус одно время - приходили чужие электронные чеки
Электронные чеки явно были задуманы, чтобы анонимизировать покупателя - в них данных о счете/номере карты, откуда платили, нет. Сама кассовая машинка же все это знает и даже на одном куске бумаги часто печатает. Но в ОФД чек идет без этого.
Это уже потом банки наловчились сопоставлять, какой чек чей по косвенным данным. Что, понятно, приводит к ошибкам.
Тоже самое у Сбера и с мегамаркетом, номер поменять не возможно, историю заказов и прочее перенести на другой номер тоже не возможно, за то свои конченые СМС они присылают на номер.
В поддержке операторы уверяют, что всё можно сделать, создают обращение на которое потом мне приходит ответ вида: "мы закрыли ваше обращение, потому что поменять номер нету технической возможности". А заказ получать как бы по коду из СМС, отправленному на бывший мой номер, который сейчас не доступен мне, так-как я закрыл договор давно.
И всё дело опять же в сбер id, в моём случае из него не подтягивает новый номер, похоже потому что "нет технической возможности".
Ну везде рассчитано на правильное простое использование. Твой телефон, твоя учётка, твои данные. И не возникает проблем. Согласитесь, что у Вас ситуация "кривая", такие и приводят к неразберихе. Извините, может не стоило вообще писать сюда, но за 25 лет ИТ я насмотрелся на это сполна.
Проблема в том, что у вас нет сбер ид. И я думаю когда это все проектировали, то предполагали, что будет конверсия клиентов еаптеки в клиентов Сбера. Так что то что с вами случилось и было задумано.
Вот такая же ситуация с Yandex книгами, когда-то это был классный сервис bookmate, после того как их выкупили Yandex с их дебильным yandexpasportoм, они просто выпилили старую систему входа, и теперь я не могу войти в свою учётную запись с компьютера на телефоне сохранилась сессия, но на компе нужно войти с начала в Yandex pasport, а я старый пароль от Yandex помню, а вот пинкод от двухфакторной мать её защиты нет, и восстановить не удаётся никак и я теперь в душе не ...знаю как войти ни в Yandex ни в bookmate, а заводить новую учетку это заново собирать библиотеку, вообще не охота
Вот такая же ситуация с Yandex книгами, когда-то это был классный сервис bookmate, после того как их выкупили Yandex с их дебильным yandexpasportoм, они просто выпилили старую систему входа
Они слегка одумались. 'иностранный' bookmate.com по старым атрибутам вроде бы стал пускать.
А вот books.yandex.ru и ru.bookmate.com - те да, яндексовская учетка.
Почему не стоит бездумно использовать SSO