Size: a a a

2020 July 19

Э

Эд in pro.jvm
подозрительно
источник

AE

Alexandr Emelyanov in pro.jvm
что не так?
источник

Э

Эд in pro.jvm
Если украдут refresh token
источник

AE

Alexandr Emelyanov in pro.jvm
отозвать
источник

Э

Эд in pro.jvm
ок, подумаю
источник

ДК

Дима Красилов... in pro.jvm
Cheat Sheet: OAuth for Browser-Based Applications (e.g. a JavaScript SPA) - Scott Brady
https://www.scottbrady91.com/OAuth/Cheat-Sheet-OAuth-for-Browser-Based-Applications
источник

ДК

Дима Красилов... in pro.jvm
@wasapWasapWasap вот статейка связанная
источник

Э

Эд in pro.jvm
Дима Красилов
Cheat Sheet: OAuth for Browser-Based Applications (e.g. a JavaScript SPA) - Scott Brady
https://www.scottbrady91.com/OAuth/Cheat-Sheet-OAuth-for-Browser-Based-Applications
да, спасибо, я наткнулся также на https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-00
источник

ДК

Дима Красилов... in pro.jvm
Эд
да, спасибо, я наткнулся также на https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-00
А какой у тебя сценарий?
источник

ДК

Дима Красилов... in pro.jvm
У меня в общем токен хранится на бэкенде.

А вебу я отдаю простую стрингу после аутентификации, которую он передает в заголовке вместо жвт.

Плюс в том, что я всегда могу разорвать сессию, так как клиент не владеет токеном.

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

Э

Эд in pro.jvm
Дима Красилов
А какой у тебя сценарий?
Тупой сценарий. Юзер вводит креды, они отправляются на бэк. Бэк делает запрос на Authorization server (AS) с кредами + client id, client secret.  AS возвращает access. Бэк кладёт в header access token, передаёт клиенту, последний ставит токен в session storage и ходит на бэк с ним в хидере
источник

ДК

Дима Красилов... in pro.jvm
Эд
Тупой сценарий. Юзер вводит креды, они отправляются на бэк. Бэк делает запрос на Authorization server (AS) с кредами + client id, client secret.  AS возвращает access. Бэк кладёт в header access token, передаёт клиенту, последний ставит токен в session storage и ходит на бэк с ним в хидере
Ну вот в статье которую я скинул, чувак рекомендует использовать bff
источник

ДК

Дима Красилов... in pro.jvm
Для максимальной секурности
источник

Э

Эд in pro.jvm
Дима Красилов
Ну вот в статье которую я скинул, чувак рекомендует использовать bff
ага, у нас как раз есть bff
источник

MM

Michael M in pro.jvm
Alexandr Emelyanov
не запилят. спрингфокс мертв
Они что-то выпустили:
https://github.com/springfox/springfox/releases/tag/3.0.0
источник

AE

Alexandr Emelyanov in pro.jvm
Michael M
Они что-то выпустили:
https://github.com/springfox/springfox/releases/tag/3.0.0
Шикарно, даже spring integration
источник

ДК

Дима Красилов... in pro.jvm
Michael M
Они что-то выпустили:
https://github.com/springfox/springfox/releases/tag/3.0.0
А в чём преимущество springfox перед springdoc?
источник

AE

Alexandr Emelyanov in pro.jvm
Дима Красилов
А в чём преимущество springfox перед springdoc?
Springdoc помнится был весьма ватным по возможностям
источник

ДК

Дима Красилов... in pro.jvm
Alexandr Emelyanov
Springdoc помнится был весьма ватным по возможностям
Я, видимо, ими не пользуюсь.

Просто в прошлый раз при миграции на спринг бут 2.2.х (который спрингфокс не поддерживал) выпиливал все спрингфоксовские аннотации и заменял на спрингдоковские
источник

ДК

Дима Красилов... in pro.jvm
И теперь думаю, а есть ли смысл обратно спрингфокс возвращать
источник