Сообщение Re[21]: Веб победил десктоп? от 09.03.2023 11:40
Изменено 09.03.2023 13:03 Serginio1
Re[21]: Веб победил десктоп?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>>Получаешь первый раз refresh token через браузер, как положено, потом по refresh token, пока он валидный, без участия пользователя можешь получать access token. Это если дело происходит на клиентском устройстве. А если server 2 server, когда можно секурно хранить секреты, то есть client credentials. Но речь тут шла не про этот сценарий.
S>> У меня как раз такой. То есть получаем рефрештокен через браузер и его используем в апи.
НС>Поздравляю. Тогда с чем ты вообще споришь?
Я не спорил, а спрашивал. Разбирался в проблеме.
Суть так или иначе лежит на апи. Там для получения токенов можно использовать суперсложные схемы как открытые закрытые ключи, так и доверенные сервисы итд.
Но вот им уже лень. Используют браузер плюс код подтверждения по почте или на телефон.
Конечно можно через тот же селениум сделать и даже почту прикрутить, но вот с телефоном нужно свое приложение с доступом к СМС, но это уже не секьюрно и непродуктивно.
Для отладки конечно можно.
Ну и если токен постоянно использовать, то он и не протухает. Вернее при протухшем токене, можно запросить новый по старому.
НС>>>Получаешь первый раз refresh token через браузер, как положено, потом по refresh token, пока он валидный, без участия пользователя можешь получать access token. Это если дело происходит на клиентском устройстве. А если server 2 server, когда можно секурно хранить секреты, то есть client credentials. Но речь тут шла не про этот сценарий.
S>> У меня как раз такой. То есть получаем рефрештокен через браузер и его используем в апи.
НС>Поздравляю. Тогда с чем ты вообще споришь?
Я не спорил, а спрашивал. Разбирался в проблеме.
Суть так или иначе лежит на апи. Там для получения токенов можно использовать суперсложные схемы как открытые закрытые ключи, так и доверенные сервисы итд.
Но вот им уже лень. Используют браузер плюс код подтверждения по почте или на телефон.
Конечно можно через тот же селениум сделать и даже почту прикрутить, но вот с телефоном нужно свое приложение с доступом к СМС, но это уже не секьюрно и непродуктивно.
Для отладки конечно можно.
Ну и если токен постоянно использовать, то он и не протухает. Вернее при протухшем токене, можно запросить новый по старому.
Re[21]: Веб победил десктоп?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>>Получаешь первый раз refresh token через браузер, как положено, потом по refresh token, пока он валидный, без участия пользователя можешь получать access token. Это если дело происходит на клиентском устройстве. А если server 2 server, когда можно секурно хранить секреты, то есть client credentials. Но речь тут шла не про этот сценарий.
S>> У меня как раз такой. То есть получаем рефрештокен через браузер и его используем в апи.
НС>Поздравляю. Тогда с чем ты вообще споришь?
Я не спорил, а спрашивал. Разбирался в проблеме.
Суть так или иначе лежит на апи. Там для получения токенов можно использовать суперсложные схемы как открытые закрытые ключи, так и доверенные сервисы итд.
Но вот им уже лень. Используют браузер плюс код подтверждения по почте или на телефон.
Конечно можно через тот же селениум сделать и даже почту прикрутить, но вот с телефоном нужно свое приложение с доступом к СМС, но это уже не секьюрно и непродуктивно.
Для отладки конечно можно.
Ну и если токен постоянно использовать, то он и не протухает. Вернее при протухшем токене, можно запросить новый по старому.
По описанной твоей схеме.
Просто в первый раз с таким сталкиваюсь. Век живи и век учись.
НС>>>Получаешь первый раз refresh token через браузер, как положено, потом по refresh token, пока он валидный, без участия пользователя можешь получать access token. Это если дело происходит на клиентском устройстве. А если server 2 server, когда можно секурно хранить секреты, то есть client credentials. Но речь тут шла не про этот сценарий.
S>> У меня как раз такой. То есть получаем рефрештокен через браузер и его используем в апи.
НС>Поздравляю. Тогда с чем ты вообще споришь?
Я не спорил, а спрашивал. Разбирался в проблеме.
Суть так или иначе лежит на апи. Там для получения токенов можно использовать суперсложные схемы как открытые закрытые ключи, так и доверенные сервисы итд.
Но вот им уже лень. Используют браузер плюс код подтверждения по почте или на телефон.
Конечно можно через тот же селениум сделать и даже почту прикрутить, но вот с телефоном нужно свое приложение с доступом к СМС, но это уже не секьюрно и непродуктивно.
Для отладки конечно можно.
Ну и если токен постоянно использовать, то он и не протухает. Вернее при протухшем токене, можно запросить новый по старому.
По описанной твоей схеме.
Получаешь первый раз refresh token через браузер, как положено, потом по refresh token, пока он валидный, без участия пользователя можешь получать access token. Это если дело происходит на клиентском устройстве. А если server 2 server, когда можно секурно хранить секреты, то есть client credentials. Но речь тут шла не про этот сценарий.
Просто в первый раз с таким сталкиваюсь. Век живи и век учись.