Если ваше "продавать" повернуть из негативного ключа и немного гарнировать, то получается общение/убеждение на различных уровнях организации (и владение их языком). То что Грегор Хоппе называет The Architect Elevator https://www.youtube.com/watch?v=Zq2VcRZmz78
Многим прагматикам из нашей IT сферы и до это-го понятно было… Но как-то осталиь неуслышаны. ЕСные чиновники тут нагородили идитоскую и контрпродуктивную хрень.
" Implicit и Password Grant — зло"
Password Grant будет исключен из OAuth версии 2.1.
Но только аккуратнее нифига он не зло. Если вы не имеете федеративности — тоесть записи ваших пользователей всеравно у вас, то проблем с ним нет. Проблема в самом OAuth фреймворке который предлагал слишком много способов и люди использовали их не по назначению и всеравно говорили, смотрите так можно по OAuth.
Тоесть просто со опытом и временем стало ясно как сформулировать стандарт и что не надо писать стандарт на все возможные случаи аутентификации а сконцентрироваться на чем-то.
Подскажите если ли игровая связка с внешним корпусом с графикартой как в этой статье это про asus, только не asus а Lenovo.
Смотрю у них в новых моделях Thunderbolt 3 идет. А это то что нужно для таких систем если не ошибаюсь...
сам блок с гафикой я бы домой себе сам купил а вот Lenovo ноут можно и шефа попросить профинансировать ;)
Просто домашний мне тогда в принципе не нужен уже совсем окажется
достаточно поверхностный анализ, даже глупый хочется сказать…
сводящий все к:
он просто имел доступ к большему, чем имели другие, капиталу, который аккуратно использовал для удушения конкурентов и для усиления своей позиции по извлечению дополнительной прибыли от простых покупателей.
ну хорошо допустим так.
а теперь копните под каждое слово и подумайте почему, доступ к капиталу,
что кроется в "капитал аккуратно использовался" — вы понимаете что в этом словосочитании вселенную спрятать можно?
"удушение конкуретнтов" что именно? иметь более привелкательный сервис чем конкуренция? ага вот пусть автор и попробует — это же так просто (и в его глзах видимо плохо)
и т.д.
Боюсь автор просто не по этой теме в принципе…
Вообще правы и не правы да ещё фундаментально не совсем уместные тут категории как мне кажется.
Рынок покажет, причем разным людям он покажет разные выводы ;)
Ну да.
Просто я с универа это в контескте SOA помню ещё, тогда небыло облаков и DevOps, лет 15 назад и больше.
И там архитектуру оркестрации противопостовляли хореографии (как и сейчас с микросервисами).
Я помню про k8s изначально писали: "Оркестратор микросервисов", что удачно имхо, ну и видимо всем понравилось и теперь тянут на весь класс т.н. DevOps-инструментов.
Мне трудно сказать есть ли эта разница в русском языке.
Но оркестрация в computing, если можно так сказать, это скорее мета-управление. Слово от "оркестр" где "орхестрированием" занимается дирижер, он не говорит как водить смычком или какие клавиши нажимать — это было бы уже управление более примитивными сущностями.
Дирижер имеет дело с самодостаточными профессионалами, которые и сами по семе могут играть а в оркестре они формируются во что-то новое.
Перенося аналогию на computing… у нас есть сервисы которы "умные" и в большей степени самодостаточны, вплодь до стандартных сервисов (авторизация, логирование, мониторинг, пользователи и т.д.). Они сами выполняют свои задачи, имеют свой лайфсайкл и т.д. — тут четкого опредиления нет, главное что ими не надо управлять из вне.
Но! их можно "орхестритовать" в новые задачи (flows). Например самодостаточный и не нуждающийся в управлении сервис аудита может быть орхестрирован в различные бизнес-процессы.
В ещё более узком понимании сейчас под оркестрацией на английских ресурсах все чаще подрузомевают автоматическую конфигурацию, развертывание и координацию аппликаций/сервисов. Например RedHat свою Ansible часто называет Orchestation tool, ну и kuberntes поэтому вполне можно так назвать и так и называют.
Не надо сравнивать теслу с этаблированными производителями в автопроме.
Правильно на рынках её сравнивать с Гугл, амазон и прочими техгигантами и их экономической моделью… так делают, кто торгует акцией Тесла.
В комментарии сложно раскырыть тему, что это значит. Куча традиционных (назовем их европейскими) инвесторов именно так как в статье рассуждают, не понимают американский технологичный сектор Рынок и его стратегии развития.
Я не хочу вовсе сказать сказать, что они не правы. Конечно такой традиционый анализ правелен и хорошо показывает определенные аспекты, комута так нагляднее становятся риски и возможно "надутость", но это далеко не описывает ситуацию полностью.
Просто советую вам вспомнить на примерах: лет 5 назад возгласы о стоимости акций Фесбука. Как его хоронили с теми же дураками которы купили эти акции. Тут же на хабре в том числе.
Про гугл уже и позабылось но и его считали глубоко пеоцененным.
И что амазон долгое время был чуть ли не убточным, европейцы качали головами или грозили пальцем — и где амазно сейчас.
и это не случайность а выстрелившая долгосторчная стратегия амазон и конца края не видно их прибыли
В ваших вопросах чувствуется некая эмоциональность, и не знаю, были ли все-таки вопросы мне адресованы или во вселенную), но надеюсь, что я смогла отчасти на что-то ответить.
Ой, если и есть эмоциональность, то только ради заострения вопроса, ничего-больше в это не вкладываю. Вам огромное спасибо за попытку разобраться!!!
Давайте попробуем:
Authorization Code Grant в 2.1 не требует обязательного использования какого-то готового агента в виде браузера
Наверно вы правы формально "user agent" не обязательно browser.
Но "user agent" это то, кому пользователь больше доверяет. "Агент пользователя", установленный (им) на его устройстве — главное что не вами!..
И именно в этом фишка в федеративном сценарии и всем этом Authorization Code Grant. Пароли не проходят никак через вашу апп!
Resource Owner Password Credentials исключаются из документа.
так вот в этом и вопрос и что в замен?
Моя личная догадка в том, что просто OAuth перестает описывать "не федеративный" сценарий коим является тот сценарий который я описываю:
Мои пользователи и их credentials проходят везде мой код и в App и в Backend…
И поэтому, воизбежания OAuth 2.1 просто перестает это описывать в своем стандарте, обьявляя мой случай проприетарным.
Мне кажется это логичным, иначе пользователи всегда будут использовать не уместные flow в федеративном сценарии. Других идей на ум не приходит пока.
Если я правильно понимаю Authorization Code Grant, то нужно что-бы мое скажем приложение открывало browser в котором логин/пароль задаются, тем самым не проходя через само приложение…
Это все очень условно секьюрно в случае с public app. И да можно наверно сойтись на том, что browser мы доверяем как-то больше чем аппликушечке от дяди Васи.
НО! мой сценарий не тот. Я сам строю свою аппликушечку. У меня нет никакой причины доверять browser больше чем аппе написаной моей крутой коммандой, для нашей же API наших же в конце концов юзеров (но просто другой API предоставленной)
Зачем мне открывать browser в моей аппе? Я считаю это ужасным UX к примеру… и я не один такой, я вижу кучу аппов не делающих это. Они просто все плевали на OAuth?
Вот этот момент мне не понятен.
Я этот момент тоже не совсем понимаю.
Как строить "правильно" с ОAuth2.1 нативной аппы которой доверяешь в имплементации (сам выпускаешь)?
Или этот стандарт просто решил не предлагать ничего для этого кейса?
Если ваше "продавать" повернуть из негативного ключа и немного гарнировать, то получается общение/убеждение на различных уровнях организации (и владение их языком). То что Грегор Хоппе называет The Architect Elevator
https://www.youtube.com/watch?v=Zq2VcRZmz78
Многим прагматикам из нашей IT сферы и до это-го понятно было… Но как-то осталиь неуслышаны. ЕСные чиновники тут нагородили идитоскую и контрпродуктивную хрень.
Неавторитет? ДДД уже все понято или неактуально… Оба стейтмента мимо кассы.
" Implicit и Password Grant — зло"
Password Grant будет исключен из OAuth версии 2.1.
Но только аккуратнее нифига он не зло. Если вы не имеете федеративности — тоесть записи ваших пользователей всеравно у вас, то проблем с ним нет. Проблема в самом OAuth фреймворке который предлагал слишком много способов и люди использовали их не по назначению и всеравно говорили, смотрите так можно по OAuth.
Тоесть просто со опытом и временем стало ясно как сформулировать стандарт и что не надо писать стандарт на все возможные случаи аутентификации а сконцентрироваться на чем-то.
Кот-то где-то в реальных проектам этим пользуется ну хотябы IPFS.
Было бы очень интересно почитать про реальные кейсы.
Пытаются протолкнуть поддержку своп с версии 1.22
Черновик с деталями
https://docs.google.com/document/d/1CZtRtC8W8FwW_VWQLKP9DW_2H-hcLBcH9KBbukie67M/edit#
Подскажите если ли игровая связка с внешним корпусом с графикартой как в этой статье это про asus, только не asus а Lenovo.
Смотрю у них в новых моделях Thunderbolt 3 идет. А это то что нужно для таких систем если не ошибаюсь...
сам блок с гафикой я бы домой себе сам купил а вот Lenovo ноут можно и шефа попросить профинансировать ;)
Просто домашний мне тогда в принципе не нужен уже совсем окажется
достаточно поверхностный анализ, даже глупый хочется сказать…
сводящий все к:
ну хорошо допустим так.
а теперь копните под каждое слово и подумайте почему, доступ к капиталу,
что кроется в "капитал аккуратно использовался" — вы понимаете что в этом словосочитании вселенную спрятать можно?
"удушение конкуретнтов" что именно? иметь более привелкательный сервис чем конкуренция? ага вот пусть автор и попробует — это же так просто (и в его глзах видимо плохо)
и т.д.
Боюсь автор просто не по этой теме в принципе…
Как чудно что по паре каментов вы поняли что ваш собеседник:
Чудило, упоротый, ущемленец, и несет бред...
Прям захотелось примкнуть к вашей священной войне за все то самое хороше, доброе и толерантое!
Именно на него с гугла перешел и все отлично..
Вообще правы и не правы да ещё фундаментально не совсем уместные тут категории как мне кажется.
Рынок покажет, причем разным людям он покажет разные выводы ;)
Ну да.
Просто я с универа это в контескте SOA помню ещё, тогда небыло облаков и DevOps, лет 15 назад и больше.
И там архитектуру оркестрации противопостовляли хореографии (как и сейчас с микросервисами).
Я помню про k8s изначально писали: "Оркестратор микросервисов", что удачно имхо, ну и видимо всем понравилось и теперь тянут на весь класс т.н. DevOps-инструментов.
Мне трудно сказать есть ли эта разница в русском языке.
Но оркестрация в computing, если можно так сказать, это скорее мета-управление. Слово от "оркестр" где "орхестрированием" занимается дирижер, он не говорит как водить смычком или какие клавиши нажимать — это было бы уже управление более примитивными сущностями.
Дирижер имеет дело с самодостаточными профессионалами, которые и сами по семе могут играть а в оркестре они формируются во что-то новое.
Перенося аналогию на computing… у нас есть сервисы которы "умные" и в большей степени самодостаточны, вплодь до стандартных сервисов (авторизация, логирование, мониторинг, пользователи и т.д.). Они сами выполняют свои задачи, имеют свой лайфсайкл и т.д. — тут четкого опредиления нет, главное что ими не надо управлять из вне.
Но! их можно "орхестритовать" в новые задачи (flows). Например самодостаточный и не нуждающийся в управлении сервис аудита может быть орхестрирован в различные бизнес-процессы.
В ещё более узком понимании сейчас под оркестрацией на английских ресурсах все чаще подрузомевают автоматическую конфигурацию, развертывание и координацию аппликаций/сервисов. Например RedHat свою Ansible часто называет Orchestation tool, ну и kuberntes поэтому вполне можно так назвать и так и называют.
Не надо сравнивать теслу с этаблированными производителями в автопроме.
Правильно на рынках её сравнивать с Гугл, амазон и прочими техгигантами и их экономической моделью… так делают, кто торгует акцией Тесла.
В комментарии сложно раскырыть тему, что это значит. Куча традиционных (назовем их европейскими) инвесторов именно так как в статье рассуждают, не понимают американский технологичный сектор Рынок и его стратегии развития.
Я не хочу вовсе сказать сказать, что они не правы. Конечно такой традиционый анализ правелен и хорошо показывает определенные аспекты, комута так нагляднее становятся риски и возможно "надутость", но это далеко не описывает ситуацию полностью.
Просто советую вам вспомнить на примерах: лет 5 назад возгласы о стоимости акций Фесбука. Как его хоронили с теми же дураками которы купили эти акции. Тут же на хабре в том числе.
Про гугл уже и позабылось но и его считали глубоко пеоцененным.
И что амазон долгое время был чуть ли не убточным, европейцы качали головами или грозили пальцем — и где амазно сейчас.
и это не случайность а выстрелившая долгосторчная стратегия амазон и конца края не видно их прибыли
Вот вот, и вовсе не факт что это лучше читатаемо. Особенно если к стримам не привыкли.
Ой, если и есть эмоциональность, то только ради заострения вопроса, ничего-больше в это не вкладываю. Вам огромное спасибо за попытку разобраться!!!
Давайте попробуем:
Наверно вы правы формально "user agent" не обязательно browser.
Но "user agent" это то, кому пользователь больше доверяет. "Агент пользователя", установленный (им) на его устройстве — главное что не вами!..
И именно в этом фишка в федеративном сценарии и всем этом Authorization Code Grant. Пароли не проходят никак через вашу апп!
так вот в этом и вопрос и что в замен?
Моя личная догадка в том, что просто OAuth перестает описывать "не федеративный" сценарий коим является тот сценарий который я описываю:
Мои пользователи и их credentials проходят везде мой код и в App и в Backend…
И поэтому, воизбежания OAuth 2.1 просто перестает это описывать в своем стандарте, обьявляя мой случай проприетарным.
Мне кажется это логичным, иначе пользователи всегда будут использовать не уместные flow в федеративном сценарии. Других идей на ум не приходит пока.
Если я правильно понимаю Authorization Code Grant, то нужно что-бы мое скажем приложение открывало browser в котором логин/пароль задаются, тем самым не проходя через само приложение…
Это все очень условно секьюрно в случае с public app. И да можно наверно сойтись на том, что browser мы доверяем как-то больше чем аппликушечке от дяди Васи.
НО! мой сценарий не тот. Я сам строю свою аппликушечку. У меня нет никакой причины доверять browser больше чем аппе написаной моей крутой коммандой, для нашей же API наших же в конце концов юзеров (но просто другой API предоставленной)
Зачем мне открывать browser в моей аппе? Я считаю это ужасным UX к примеру… и я не один такой, я вижу кучу аппов не делающих это. Они просто все плевали на OAuth?
Вот этот момент мне не понятен.
P.S.
Ещё два года назад все было Ок:
https://developer.okta.com/blog/2018/06/29/what-is-the-oauth2-password-grant
что поменялось и как это теперь реализовывать?
Я этот момент тоже не совсем понимаю.
Как строить "правильно" с ОAuth2.1 нативной аппы которой доверяешь в имплементации (сам выпускаешь)?
Или этот стандарт просто решил не предлагать ничего для этого кейса?
А где можно почитать про их движок и пайплайн?
Спасибо, это хорошие новости.