Здравствуйте, CreatorCray, Вы писали: CC>То, что кто то сделал сайт с калькулятором никак не отвечает на вопрос когда локальный калькулятор перепишут на электрон.
А вот и подмена тезиса. Только что речь шла о
Нахрена ему что то вне локальной машины?
И вдруг мы перепрыгнули с топологии деплоймента к технологии отображения.
Ну, ок — калькулятор на электроне, очевидно, прекрасен тем, что предсказуемо себя ведёт и отображается на любой платформе.
Я, кстати, не особо уверен, что в Win11 калькулятор ещё не на электроне.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Serginio1, Вы писали:
S> Спасибо. Я читал.
Не заметно.
S> У меня другая ситуация.
Нет, у тебя та же самая ситуация.
S> У меня есть пароль логин. Но работать мне надо не через браузер, а через API используя токен, который протухает.
Получаешь первый раз refresh token через браузер, как положено, потом по refresh token, пока он валидный, без участия пользователя можешь получать access token. Это если дело происходит на клиентском устройстве. А если server 2 server, когда можно секурно хранить секреты, то есть client credentials. Но речь тут шла не про этот сценарий.
Здравствуйте, Serginio1, Вы писали:
НС>>Какой именно? S> Да любой.
Любой в современном мире означает ровно два варианта, OAuth2/OIDC или SAML 2.0. Причем последним стоит пользоваться только в особых случаях. А про первый я тебе вроде бы уже все по теме рассказал.
S> Обычно кроме вэб морду есть некий апи, что бы через него с сайтом обмениваться данными обмениваться.
И этот API включает в себя использование браузера (auth code flow и device flow). Без браузера в случае OAuth2 есть implicit и ropc, которые объявлены небезопасным, и client crdentials, который предполагает развертывание клиентского приложения в контролируемой с точки зрения безопасности среде, а не на устройстве клиента.
Для окты пишешь отдельный скрипт. Потом для one login. А позавчера вот с неким F5 денежный клиент пришел. И да, если что то поменяют (а это могу сделать без предупреждения) — у тебя опять жопа в мыле. Зато job security навысоте
C>Можно попробовать сделать так, что приложение прикидывается "умным телевизором", и использует соответствующий workflow: https://auth0.com/docs/get-started/authentication-and-authorization-flow/device-authorization-flow
Но там все равно надо открывать в браузере страничку и вводить код, просто устройство при этом может быть другим и никакого допсофта кроме браузера там не нужно.
C> Но это небезопасно, и будет работать далеко не со всеми SSO (с моим, например, не будет).
Последнее время вроде бы почти все основные IdP это умеют, но по дефолту почти везде оно запрещено, надо явно врубать в настройках. И да, IdP может быть не общеупотребимым, а встроенным в какое нибудь решение, и там возможны любые варианты, от явного отключения без возможности включить, и до полностью доморощенной реализации OIDC (или даже голого OAuth2) в котором реализация отсутствует в принципе.
S>> У меня есть пароль логин. Но работать мне надо не через браузер, а через API используя токен, который протухает.
НС>Получаешь первый раз refresh token через браузер, как положено, потом по refresh token, пока он валидный, без участия пользователя можешь получать access token. Это если дело происходит на клиентском устройстве. А если server 2 server, когда можно секурно хранить секреты, то есть client credentials. Но речь тут шла не про этот сценарий.
У меня как раз такой. То есть получаем рефрештокен через браузер и его используем в апи.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
НС>>Получаешь первый раз 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. Но речь тут шла не про этот сценарий.
Просто в первый раз с таким сталкиваюсь. Век живи и век учись.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Ночной Смотрящий, Вы писали:
НС> R>По делу-то можешь что-то возразить, или как обычно?
НС> По делу я дал Serginio ссылку на RFC и даже цитату оттуда. Кури до появления понимания.
Да ты не в rfc тыкай, а расскажи, о какой безопасно ты ведешь речь, допуская ситуацию с поддельным окном логина на десктопе. Очень интересно.
Здравствуйте, Pauel, Вы писали:
P>Берем Skype, Teams, Slack, GitKraken, Github Desktop, Spotify, Tidal, Qobuz итд итд — все они работают на Виндовс, Макос и линукс. Вы можете себе представить такую кроссплатформенность на WPF? Ан нет — WPF это чисто виндовая технология.
Кроссплатформенность на WPF или WinForms я себе представить не могу. Настоящую кроссплатформенность мог предоставить только стандартный Фортран. Говорят, что и Кобол, но утверждать не буду. Фортран я переносил между ОСями, а Кобол — нет.
Извините, не удержался.
<КСВ on>
Я не слышал, чтобы на Фортране и Коболе кто-то писал для Веб. Значит, Веб не нужен.
<КСВ off>
Здравствуйте, Privalov, Вы писали:
P><КСВ on> P>Я не слышал, чтобы на Фортране и Коболе кто-то писал для Веб. Значит, Веб не нужен. P><КСВ off>
<CreatorCray on>
Я пишу на Фортране, я практик, на моей машине ничего кроме Фортрана нет. Веб — не нужен!!!!!11111111йййййqqqqqкукуку
<CreatorCray off>
Здравствуйте, Serginio1, Вы писали:
НС>>Поздравляю. Тогда с чем ты вообще споришь? S>Я не спорил, а спрашивал.
Вот это ты тоже так спрашивал, да?
Хотя опять же можно форму запросить и не показывать пользователю, а передать данные из нативной формы. Это просто лень некоторых товарищей
S> Суть так или иначе лежит на апи. Там для получения токенов можно использовать суперсложные схемы как открытые закрытые ключи, так и доверенные сервисы итд. S> Но вот им уже лень.
Кому им?
S>Используют браузер плюс код подтверждения по почте или на телефон.
Чувак, еще раз — иди и внимательно почитай, причины почему нужно использовать системный браузер по ссылке подробно описаны, нужды насасывать из пальца левые мотивы нет.
S> Конечно можно через тот же селениум сделать
Нельзя.
S>Ну и если токен постоянно использовать, то он и не протухает.
Нет. Во всех известных мне приличных IdP даже если sliding expiration поддерживается, absolute expiration имеет приоритет, и бесконечное время жизни access token на проде это шиза. Это означает что рано или поздно и access token и refresh token протухнут.
S>Вернее при протухшем токене, можно запросить новый по старому.
Только пока refresh token не протух. Он, конечно, обычно месяца три живет и "эксперты по безопасности" про это забывают. Но не суть. Разговор про токены начинался с того факта, что без браузера SSO по нормальному не сделать, и refresh token тебе таки придется через браузер получить.
Здравствуйте, Pauel, Вы писали:
P><CreatorCray on> P>Я пишу на Фортране, я практик, на моей машине ничего кроме Фортрана нет. Веб — не нужен!!!!!11111111йййййqqqqqкукуку P><CreatorCray off>
Могу продолжить: у меня на машине Фортрана нет, но и без него я не пишу для Веба. Значит, Веб не нужен! 11111111
Здравствуйте, Privalov, Вы писали:
P>><CreatorCray on> P>>Я пишу на Фортране, я практик, на моей машине ничего кроме Фортрана нет. Веб — не нужен!!!!!11111111йййййqqqqqкукуку P>><CreatorCray off>
P>Могу продолжить: у меня на машине Фортрана нет, но и без него я не пишу для Веба. Значит, Веб не нужен! 11111111
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>>Поздравляю. Тогда с чем ты вообще споришь? S>>Я не спорил, а спрашивал.
НС>Вот это ты тоже так спрашивал, да? НС>
НС>Хотя опять же можно форму запросить и не показывать пользователю, а передать данные из нативной формы. Это просто лень некоторых товарищей
Для тестов и собственных разработок вполне себе приемлемый способ!
S>> Суть так или иначе лежит на апи. Там для получения токенов можно использовать суперсложные схемы как открытые закрытые ключи, так и доверенные сервисы итд. S>> Но вот им уже лень.
НС>Кому им?
S>>Используют браузер плюс код подтверждения по почте или на телефон.
НС>Чувак, еще раз — иди и внимательно почитай, причины почему нужно использовать системный браузер по ссылке подробно описаны, нужды насасывать из пальца левые мотивы нет.
Читал. Какой большой толк от использования апи?
Если есть данные для авторизации, то нахрен этот браузер.
С открытым и закрытым ключем. Кучу всего сделать. Вспоминаем основы криптографии про Алису и Боба
Можно тот же токен отправлять на доверенный адрес. Тогда уж даже имея логин пароль токен взломщику не получить!
S>> Конечно можно через тот же селениум сделать
НС>Нельзя.
Можно. Примеры тебе уже приводил. В том числе при высылке кода подтверждения по СМС или на почту.
Проблема только в том, что страница авторизации может меняться.
Понятно, что такое применять можно только для тестов. Но можно.
S>>Ну и если токен постоянно использовать, то он и не протухает.
НС>Нет. Во всех известных мне приличных IdP даже если sliding expiration поддерживается, absolute expiration имеет приоритет, и бесконечное время жизни access token на проде это шиза. Это означает что рано или поздно и access token и refresh token протухнут.
S>>Вернее при протухшем токене, можно запросить новый по старому.
НС>Только пока refresh token не протух. Он, конечно, обычно месяца три живет и "эксперты по безопасности" про это забывают. Но не суть. Разговор про токены начинался с того факта, что без браузера SSO по нормальному не сделать, и refresh token тебе таки придется через браузер получить.
Да и хрен с ним! Один раз в 3 месяца это проблема клиента. Может к тому времени и через апи сделают. И вспомнят про Алису с Бобом!
Это проблема с хозяином хоста я так понял не раз подымалась.
и солнце б утром не вставало, когда бы не было меня
Тем более, что я действительно не пишу для Веба. 