Регистрация  |  Вход

SOAP API login() Retirement

Всем привет, казалось бы малозначительная новость, но как мне кажется не все так просто.
В краце: если вы ISV и используете какое-то расширение для браузера, которое позволяет логиниться в клиентские орги, то это потенциальная проблема

Почему:
1. Если ваше расширение хранит пароли локально, то это вообще не безопасно, особенно в случае увольнения сотрудника
2. Если вы используете расширение типа LASTPASS, это не проблема, но в этом случае вы теряете автоматизацию логина, так как в lastpass нужно будет делать еще один дополнительный шаг, не критично но не удобно
3. Вы скажите используй LMA, возможно, но не всегда, потому что если у вас не managed пакет, удачи вам с этим. Ну и прямо скажем LMA и морально и физически устарел. Могу сделать отдельную тему про него.
4. Что по поводу CI/CD? Интересно, как это все будет работать в этом случае
5. Вы построили свою инфраструктуру (мой случай), в этом случае есть SF org, где хранятся все пароли и дополнительная инфа нужная для правильной работы ci/cd, там же реализован стандартный sharing проектов и паролей. Так же реализовано browser extension. И теперь мне предлагают перейти на connected App или External Client App. Не совсем понятно что в этом случае будет с clientId и client secret?


У кого какие мысли?

P.S. Сделал reverse engineering Salesforce1, так в ней они используют абсолютно другой механизм авторизации. Я конечно могу сделать тоже самое, но это как-то не комильфо.
Всем привет, казалось бы малозначительная [url=https://help.salesforce.com/s/articleView?id=005132110&type=1]новость[/url], но как мне кажется не все так просто.
В краце: если вы ISV и используете какое-то расширение для браузера, которое позволяет логиниться в клиентские орги, то это потенциальная проблема

Почему:
1. Если ваше расширение хранит пароли локально, то это вообще не безопасно, особенно в случае увольнения сотрудника
2. Если вы используете расширение типа LASTPASS, это не проблема, но в этом случае вы теряете автоматизацию логина, так как в lastpass нужно будет делать еще один дополнительный шаг, не критично но не удобно
3. Вы скажите используй LMA, возможно, но не всегда, потому что если у вас не managed пакет, удачи вам с этим. Ну и прямо скажем LMA и морально и физически устарел. Могу сделать отдельную тему про него.
4. Что по поводу CI/CD? Интересно, как это все будет работать в этом случае
5. Вы построили свою инфраструктуру (мой случай), в этом случае есть SF org, где хранятся все пароли и дополнительная инфа нужная для правильной работы ci/cd, там же реализован стандартный sharing проектов и паролей. Так же реализовано browser extension. И теперь мне предлагают перейти на connected App или External Client App. Не совсем понятно что в этом случае будет с clientId и client secret?


[b]У кого какие мысли?[/b]

P.S. Сделал reverse engineering Salesforce1, так в ней они используют абсолютно другой механизм авторизации. Я конечно могу сделать тоже самое, но это как-то не комильфо. 
Попробую поучаствовать в дискуссии.

Вопрос, а зачем вообще хранить и использовать username/password?

Connected App + Access Token + Refresh Token разве не то что должно быть в этом случае?

Пользователь для логина использует Connected App, дает разрешение получается Access Token + Refresh Token и дальше сервис пользуется или хоть целую вечность.

Вроде же так и IDE все сейчас работают. И если не ошибаюсь SF CLI.

Это же общепринятый стандард OAuth. Вполне себе безопасный.

И я не думаю что переход на Connected App (OAuth) такой болезненный. Просто при очередном использовании твоего энстеншена попросить пользователя залогиниться для OAuth.

Просто теперь вместо Username+Password будешь хранить Access Token + Refresh Token.

Возможно (как меня когда-то) смутила один вопрос - Connected App должен быть установлен у клиента на орга. Вообще это не так. Один раз создаешь его на любом орга (хоть на Dev) и использвешь его для логина на любые орги. Для конечного пользователя просто один раз надо будет редирактнуться на страницу login, залогиниться и подтвердить что Connected App может иметь доступ к его учетным данным.
Попробую поучаствовать в дискуссии. 

Вопрос, а зачем вообще хранить и использовать username/password?

Connected App + Access Token + Refresh Token разве не то что должно быть в этом случае? 

Пользователь для логина использует Connected App, дает разрешение получается Access Token + Refresh Token и дальше сервис пользуется или хоть целую вечность.

Вроде же так и IDE все сейчас работают. И если не ошибаюсь SF CLI.

Это же общепринятый стандард OAuth. Вполне себе безопасный.

И я не думаю что переход на Connected App (OAuth) такой болезненный. Просто при очередном использовании твоего энстеншена попросить пользователя залогиниться для OAuth.

Просто теперь вместо Username+Password будешь хранить Access Token + Refresh Token.

Возможно (как меня когда-то) смутила один вопрос - Connected App должен быть установлен у клиента на орга. Вообще это не так. Один раз создаешь его на любом орга (хоть на Dev) и использвешь его для логина на любые орги. Для конечного пользователя просто один раз надо будет редирактнуться на страницу login, залогиниться и подтвердить что Connected App может иметь доступ к его учетным данным. 

У меня так IC2 все проекты через OAuth подрублены. Самому старому уже 4 года. Все работает и не нужны никакие логины пароли или подтверждения.
У меня так IC2 все проекты через OAuth подрублены. Самому старому уже 4 года. Все работает и не нужны никакие логины пароли или подтверждения.
Кстати я не писал, но хотел как-то упомянуть, да забил.

Отменили полный IP Range (0.0.0.0 - 255.255.255.255) чтобы Verification Code при логине не приходил. Вот это обидно. У меня сейчас каждый раз как захожу на sandbox нужно verification code вводить. А разбираться какие у меня там IP Ranges лень (часто VPS приходится использовать). Раньше один раз забил что ВСЕ IP адреса разрешены, а сейчас не более 16,777,216 адресов.

https://help.salesforce.com/s/articleVie ... 4&type=1
Кстати я не писал, но хотел как-то упомянуть, да забил. 

Отменили полный IP Range (0.0.0.0 - 255.255.255.255) чтобы Verification Code при логине не приходил. Вот это обидно. У меня сейчас каждый раз как захожу на sandbox нужно verification code вводить. А разбираться какие у меня там IP Ranges лень (часто VPS приходится использовать). Раньше один раз забил что ВСЕ IP адреса разрешены, а сейчас не более 16,777,216 адресов.

https://help.salesforce.com/s/articleView?id=005220394&type=1
https://help.salesforce.com/s/articleView?id=release-notes.rn_api_upcoming_retirement_258rn.htm&release=258&type=5
не смотрел сколько времени это изменение сидит в Release Update (в прошлом Critical Updates в setup), но наверно давно
https://help.salesforce.com/s/articleVie ... 0&type=1

не смотрел сколько времени это изменение сидит в Release Update (в прошлом Critical Updates в setup), но наверно давно
https://help.salesforce.com/s/articleView?id=005132110&type=1

:sad:
Eric
не смотрел сколько времени это изменение сидит в Release Update (в прошлом Critical Updates в setup), но наверно давно
https://help.salesforce.com/s/articleVie ... 0&type=1
а чего на испанском выдало?
Retirada de login() de la API de SOAP
[quote="Eric"]не смотрел сколько времени это изменение сидит в Release Update (в прошлом Critical Updates в setup), но наверно давно
https://help.salesforce.com/s/articleVie ... 0&type=1
[/quote]
а чего на испанском выдало? 
Retirada de login() de la API de SOAP
Dmitry Shnyrev
а чего на испанском выдало?

у меня на английском
right click "Translate to English"
[quote="Dmitry Shnyrev"]а чего на испанском выдало?[/quote]
:surprised:
у меня на английском
right click "Translate to English"
Eric
right click "Translate to English"
У меня только Translate to Русский
Но все равно интересно чего так случилось.
Хотя может из-за VPN (приходится использовать часто).
[quote="Eric"]right click "Translate to English"[/quote]
У меня только Translate to Русский :rolling:
Но все равно интересно чего так случилось.
Хотя может из-за VPN (приходится использовать часто).
Dmitry Shnyrev
Connected App + Access Token + Refresh Token разве не то что должно быть в этом случае?

В этом случае будет один дополнительный шаг, разрешить connected app для каждого клиентского орга, а их сотни

Dmitry Shnyrev
У меня так IC2 все проекты через OAuth подрублены. Самому старому уже 4 года. Все работает и не нужны никакие логины пароли или подтверждения.

А вот это как раз проблема, особенно после увольнения человека
[quote="Dmitry Shnyrev"]Connected App + Access Token + Refresh Token разве не то что должно быть в этом случае?[/quote]

В этом случае будет один дополнительный шаг, разрешить connected app для каждого клиентского орга, а их сотни

[quote="Dmitry Shnyrev"]У меня так IC2 все проекты через OAuth подрублены. Самому старому уже 4 года. Все работает и не нужны никакие логины пароли или подтверждения.[/quote]

А вот это как раз проблема, особенно после увольнения человека
wilder
В этом случае будет один дополнительный шаг, разрешить connected app для каждого клиентского орга, а их сотни
Это ДА! придется проходить этот шаг.

wilder
А вот это как раз проблема, особенно после увольнения человека
Что значит увольнения? Деактивация пользователя в SF? Вот это интересный момент, не проверял кстати. НО по идее не должно работать если пользователя деактивировать. Косвенно я могу об этом судить потому что все OAuth соединения пишутся в Login History самого пользователя. Собственно как и если ты запрашиваешь User Details ты видишь под каким ты пользователем подключен. Значит по этой логике 99% что деактивация пользователя разорвет все OAuth соединения.
[quote="wilder"]В этом случае будет один дополнительный шаг, разрешить connected app для каждого клиентского орга, а их сотни[/quote]
Это ДА! придется проходить этот шаг.

[quote="wilder"]А вот это как раз проблема, особенно после увольнения человека[/quote]
Что значит увольнения? Деактивация пользователя в SF? Вот это интересный момент, не проверял кстати. НО по идее не должно работать если пользователя деактивировать. Косвенно я могу об этом судить потому что все OAuth соединения пишутся в Login History самого пользователя. Собственно как и если ты запрашиваешь User Details ты видишь под каким ты пользователем подключен. Значит по этой логике 99% что деактивация пользователя разорвет все OAuth соединения. 
wilder
А вот это как раз проблема, особенно после увольнения человека
Зато плюс OAuth что если логин или пароль меняются не надо их менять в других местах. Client Id и Client Secret остаются старые.
[quote="wilder"]А вот это как раз проблема, особенно после увольнения человека[/quote]
Зато плюс OAuth что если логин или пароль меняются не надо их менять в других местах. Client Id и Client Secret остаются старые. 
wilder
Всем привет, казалось бы малозначительная новость, но как мне кажется не все так просто.
О! Блин! А чего это я совсем забыл что у меня все python скрипты для работы с SF завязаны на username+password и login()
Да и старый добрый Ant Migration Tool (до сих пор пользуюсь ) наверное тоже login() использует.
[quote="wilder"]Всем привет, казалось бы малозначительная новость, но как мне кажется не все так просто.[/quote]
О! Блин! А чего это я совсем забыл что у меня все python скрипты для работы с SF завязаны на username+password и login() :surprised: 
Да и старый добрый Ant Migration Tool (до сих пор пользуюсь :smiley:) наверное тоже login() использует.
ещё есть время до Summer 27 release, примерно июнь 2027 года.
ближайший release в феврале 2026 - Spring 26
ещё есть время до Summer 27 release, примерно июнь 2027 года.
ближайший release в феврале 2026 - Spring 26