Сообщение Re[35]: Веб победил десктоп? от 10.03.2023 10:14
Изменено 10.03.2023 10:24 Serginio1
Re[35]: Веб победил десктоп?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Еще раз для особо непробиваемых. Для OAuth2 есть ровно 3 актуальных способа логина:
НС>1) Auth code flow. Открывает системный браузер на том устройстве, где выполняется логин.
НС>2) Devide code flow. То же самое, но браузер можно руками открыть на любом устройстве вводя специальный урл и device код руками или через QR, что позволяет логиниться на устройствах без браузера и даже клавиатуры.
НС>3) Client credentials. Для сценария когда взаимодействуют два сервиса, развернутых в контролируемом с точки зрения безопасности окружении (на своем сервере), браузер не нужен, используется shared secret в виде некоей секретной строки или серта. При этом, разумеется, необходимо безопасное хранение этого секрета, поэтому и не годится для развертывания на клиентских устройствах, а тем более при работе в браузере.
НС>Все остальный варианты небезопасны и применять их не следует.
Вот у них Client credentials. Нужен рефрештокен. Который достается через cef приложение
S>>Изначально они задумывали только как вэб. Но потом оказалось, что нужно работать через кучу устройств где проще работать через приложения и обмениваться данными с сервисом.
S>>В итоге у них есть свой апи
У сервиса с которым я работаю.
S>>Просто задумывали одно, а получилось совсем другое.
НС>Или просто кто то чего то не понимает и несет бред.
Ну те люди кто с ними контактировали все прекрасно понимают. Не такие тупые как я. Ну я и код вижу их кстати библиотеки. Там идет передача рефреш токена. Поинтересуюсь конечно еще.
Но ругаются многие клиенты.
НС>Еще раз для особо непробиваемых. Для OAuth2 есть ровно 3 актуальных способа логина:
НС>1) Auth code flow. Открывает системный браузер на том устройстве, где выполняется логин.
НС>2) Devide code flow. То же самое, но браузер можно руками открыть на любом устройстве вводя специальный урл и device код руками или через QR, что позволяет логиниться на устройствах без браузера и даже клавиатуры.
НС>3) Client credentials. Для сценария когда взаимодействуют два сервиса, развернутых в контролируемом с точки зрения безопасности окружении (на своем сервере), браузер не нужен, используется shared secret в виде некоей секретной строки или серта. При этом, разумеется, необходимо безопасное хранение этого секрета, поэтому и не годится для развертывания на клиентских устройствах, а тем более при работе в браузере.
НС>Все остальный варианты небезопасны и применять их не следует.
Вот у них Client credentials. Нужен рефрештокен. Который достается через cef приложение
S>>Изначально они задумывали только как вэб. Но потом оказалось, что нужно работать через кучу устройств где проще работать через приложения и обмениваться данными с сервисом.
S>>В итоге у них есть свой апи
У сервиса с которым я работаю.
S>>Просто задумывали одно, а получилось совсем другое.
НС>Или просто кто то чего то не понимает и несет бред.
Ну те люди кто с ними контактировали все прекрасно понимают. Не такие тупые как я. Ну я и код вижу их кстати библиотеки. Там идет передача рефреш токена. Поинтересуюсь конечно еще.
Но ругаются многие клиенты.
Re[35]: Веб победил десктоп?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Еще раз для особо непробиваемых. Для OAuth2 есть ровно 3 актуальных способа логина:
НС>1) Auth code flow. Открывает системный браузер на том устройстве, где выполняется логин.
НС>2) Devide code flow. То же самое, но браузер можно руками открыть на любом устройстве вводя специальный урл и device код руками или через QR, что позволяет логиниться на устройствах без браузера и даже клавиатуры.
НС>3) Client credentials. Для сценария когда взаимодействуют два сервиса, развернутых в контролируемом с точки зрения безопасности окружении (на своем сервере), браузер не нужен, используется shared secret в виде некоей секретной строки или серта. При этом, разумеется, необходимо безопасное хранение этого секрета, поэтому и не годится для развертывания на клиентских устройствах, а тем более при работе в браузере.
НС>Все остальный варианты небезопасны и применять их не следует.
Вот у них Client credentials. Но нужен рефрештокен. Который достается через cef или selenium приложение.
Который обновляется по старому рефрештокену. После обновления страрый рефрештокен протухает.
S>>Изначально они задумывали только как вэб. Но потом оказалось, что нужно работать через кучу устройств где проще работать через приложения и обмениваться данными с сервисом.
S>>В итоге у них есть свой апи
У сервиса с которым я работаю.
S>>Просто задумывали одно, а получилось совсем другое.
НС>Или просто кто то чего то не понимает и несет бред.
Ну те люди кто с ними контактировали все прекрасно понимают. Не такие тупые как я. Ну я и код вижу, их кстати библиотеки. При авторизации идет передача рефреш токена и получается новый или текущий рефрештокен. Поинтересуюсь конечно еще.
Но ругаются многие клиенты.
НС>Еще раз для особо непробиваемых. Для OAuth2 есть ровно 3 актуальных способа логина:
НС>1) Auth code flow. Открывает системный браузер на том устройстве, где выполняется логин.
НС>2) Devide code flow. То же самое, но браузер можно руками открыть на любом устройстве вводя специальный урл и device код руками или через QR, что позволяет логиниться на устройствах без браузера и даже клавиатуры.
НС>3) Client credentials. Для сценария когда взаимодействуют два сервиса, развернутых в контролируемом с точки зрения безопасности окружении (на своем сервере), браузер не нужен, используется shared secret в виде некоей секретной строки или серта. При этом, разумеется, необходимо безопасное хранение этого секрета, поэтому и не годится для развертывания на клиентских устройствах, а тем более при работе в браузере.
НС>Все остальный варианты небезопасны и применять их не следует.
Вот у них Client credentials. Но нужен рефрештокен. Который достается через cef или selenium приложение.
Который обновляется по старому рефрештокену. После обновления страрый рефрештокен протухает.
S>>Изначально они задумывали только как вэб. Но потом оказалось, что нужно работать через кучу устройств где проще работать через приложения и обмениваться данными с сервисом.
S>>В итоге у них есть свой апи
У сервиса с которым я работаю.
S>>Просто задумывали одно, а получилось совсем другое.
НС>Или просто кто то чего то не понимает и несет бред.
Ну те люди кто с ними контактировали все прекрасно понимают. Не такие тупые как я. Ну я и код вижу, их кстати библиотеки. При авторизации идет передача рефреш токена и получается новый или текущий рефрештокен. Поинтересуюсь конечно еще.
Но ругаются многие клиенты.