Идея refresh token — это идея oAuth2, а не JWT.
И как раз этот токен предназначен для того, чтобы пользователю не приходилось вводить пароль снова и снова.
Никто не мешает вам сделать JWT токен долгоживущим, если вы по какой-то странной причине считаете это нужным.
Никто не запрещает вам добавить проверку JWT токена в черном списке, как я сказал выше.
Разница и профит в том, что вам не надо напрягать сервер авторизации для такой проверки.
Но вообще говоря, короткоживущий токен рекомендуется в oAuth2 вообще и вне зависимости от механизма валидации.
Если действительно надо, то никто не мешает добавить в процедуру валидации токена проверку его наличия в каком нибудь централизованном черном списке, если это необходимо.
Хм, так а какая альтернатива? Вы предлагаете восстанавливать сессии? А как с безопасностью?
К JWT это вообще отношения не имеет. Если безопасность не проблема — восстанавливайте сессии с authorisation server по куки (или еще как нибудь) невидимо для пользователя и открывайте ему сразу страницу его банковского счета, например.
Мы используем oAuth2 JWT от MS Azure для доступа к нашим API. Все как часики и с пол пинка. Можно даже не использовать refresh token. MS поставляет JS библиотеку которая обходится без refresh token, если есть такая необходимость. Для например SPA все замечательно. Пока есть сессия — токен автоматически, невидимо для пользователя, обновляется.
При чем тут «так любит»? Вы сами признали что альтернативы нет. IP фильтрация лишь дополняет механизм валидации, а не заменяет его. Это даже не вопрос JWT, а любого oAuth2 токена. Т.к. даже если вы будете валидировать токен через внешний сервер, результаты этой валидации обычно кэшируются на сервере на некоторое время сравнимое со временем жизни JWT.
Заявление в стиле «зачем вам MS если есть Linux» или vice versa.
Для интеграции кроме упомянутых вами Camel и Spring есть еще куча проприетарных (MS, IBM, Oracle etc), опенсоурсных и промежуточных (типа MulrSoft) решений. Зачем они все казалось бы?
Дипломаты и институты ООН имеют особый статус. Так, северокорейцы и кубинцы имеют возможность выступать с трибуны ООН, а США обязана их впускать не смотря на все возможные санкции и даже состояние войны.
Короче говоря, есть поле международного законодательства и некоторые организации существуют исключительно в нем.
По всей видимости, порочна сама практика привязки свободной лицензий к законодательству одной страны.
Интересно, есть ли версия линкуса, поддерживаемая/распространяемая какой нибудь из структур ООН или Юнеско? Т.е. чтобы эта структура обладала иммунитетом от местного законодательства?
Вот очередная статья из серии «hello word» на котлин, которые регулярно появляются на хабре не первый год.
Когда уже можно будет почитать на хабре уже и что нибудь более серьезное? -Написать хелло ворд уже все успели.
Хотелось бы более критической, профессиональной и независимой оценки, что в котлине хорошо, что — не очень. Идеальных языков не бывает. А щенячий восторг статей намекает на недостаток опыта и профессионализма у авторов.
Вот как живет котлин в больших проектах, какие фремворки используются, библиотеки?
Общие утверждения типа «все как и в джава» бесполезны, т.к. во-первых для этого надо знать java, а во-вторых, там далеко не все так очевидно, как утверждают всякие «популяризаторы» котлина, весь опыт которых заключается в прочтении базовой документации по языку.
Дело не в том, как это назвать. Дело в том, что имеется две лицензии на продукт и один полноправный владелец заинтересованный в том, чтобы клиенты платили.
Нет, почему-же? Как раз таки Mule остается открытым в комьюнити эдишн.
Так же, старый вариант коннектора все еще открыт.
Вообщем, я не вижу причину, по которой владелец ПО не сможет в определенный момент сказать, что вот эта вот функциональность будет доступна только в платной версии и начнет отвергать коммиты с аналогичной функциональностью в публичную версию.
Ну и важнейшим моментом тут является именно мотивация. Понятно, что владелец заинтересован в том, чтобы пользователи переходили с бесплатной на платную версию.
И полный контроль над кодом дает ему в руки хороший рычаг для стимуляции пользователей двигаться в этом направлении. У мulesoft это напоминает выкручивание рук.
Столкнулись с двойным лицензированием на Mule. Это чистый ад и трэш. В один прекрасный момент mulesoft говорит: «а с версии такой-то, этот коннектор становится проприетарным». Усе.
Так что теперь, когда я слышу про двойное лицензирование, то жду подвоха.
На мой взгляд, часто достаточно изучить какой-то фреймворк или библиотеку, чтобы найти работу в АйТи. «Гениев», готовых освоить, то дофига. А когда проекту срочно нужен человек просто владеющий чем-то специфическим, то могут быть сложности с поиском и есть шанс получить работу без всякого другого опыта или высшего образования.
Я не уверен, что вы поняли о чем речь. Речь о JSON схеме. А она как раз позволяет описывать данные гораздо более точно. Скажем, для Int задавать граничные значения. Ну и конечно существуют библиотеки, чтобы генерить классы из схемы или и json.
А JSON схема чем плоха? Но дело даже не в этом. Я не понимаю мотивации в описании схемы БД в терминах протобуф IDL. Может есть какой-то годный фреймворк, позволющий удобно все эти описания переводить в DDL?
И как раз этот токен предназначен для того, чтобы пользователю не приходилось вводить пароль снова и снова.
Никто не мешает вам сделать JWT токен долгоживущим, если вы по какой-то странной причине считаете это нужным.
Никто не запрещает вам добавить проверку JWT токена в черном списке, как я сказал выше.
Разница и профит в том, что вам не надо напрягать сервер авторизации для такой проверки.
Но вообще говоря, короткоживущий токен рекомендуется в oAuth2 вообще и вне зависимости от механизма валидации.
К JWT это вообще отношения не имеет. Если безопасность не проблема — восстанавливайте сессии с authorisation server по куки (или еще как нибудь) невидимо для пользователя и открывайте ему сразу страницу его банковского счета, например.
Для интеграции кроме упомянутых вами Camel и Spring есть еще куча проприетарных (MS, IBM, Oracle etc), опенсоурсных и промежуточных (типа MulrSoft) решений. Зачем они все казалось бы?
Короче говоря, есть поле международного законодательства и некоторые организации существуют исключительно в нем.
Интересно, есть ли версия линкуса, поддерживаемая/распространяемая какой нибудь из структур ООН или Юнеско? Т.е. чтобы эта структура обладала иммунитетом от местного законодательства?
Когда уже можно будет почитать на хабре уже и что нибудь более серьезное? -Написать хелло ворд уже все успели.
Хотелось бы более критической, профессиональной и независимой оценки, что в котлине хорошо, что — не очень. Идеальных языков не бывает. А щенячий восторг статей намекает на недостаток опыта и профессионализма у авторов.
Вот как живет котлин в больших проектах, какие фремворки используются, библиотеки?
Общие утверждения типа «все как и в джава» бесполезны, т.к. во-первых для этого надо знать java, а во-вторых, там далеко не все так очевидно, как утверждают всякие «популяризаторы» котлина, весь опыт которых заключается в прочтении базовой документации по языку.
Так же, старый вариант коннектора все еще открыт.
Вообщем, я не вижу причину, по которой владелец ПО не сможет в определенный момент сказать, что вот эта вот функциональность будет доступна только в платной версии и начнет отвергать коммиты с аналогичной функциональностью в публичную версию.
Ну и важнейшим моментом тут является именно мотивация. Понятно, что владелец заинтересован в том, чтобы пользователи переходили с бесплатной на платную версию.
И полный контроль над кодом дает ему в руки хороший рычаг для стимуляции пользователей двигаться в этом направлении. У мulesoft это напоминает выкручивание рук.
Так что теперь, когда я слышу про двойное лицензирование, то жду подвоха.