D
Да, спасибо, и ещё один вопрос: "Сильно ли медленней Spring Data по сравнению с обычным JDBC или тут уже зависит от прямоты рук разработчика?"
это вопросы с собеседования чтоли?
Size: a a a
2021 February 08
DC
это вопросы с собеседования чтоли?
лол
A
Еще подскажите пожалуйста как сделать чтобы из spring boot логи попадали в logstash (а дальше в elk) но при это в определенный индекс. Например если приложение крутится на тесте то имя индекса на сегодня app_test1_2021_02_08 а если прод и вчера то app_2021_02_07
Непонятно где именно настраиваются имена индексов elastic
Непонятно где именно настраиваются имена индексов elastic
A
С контрольной может ?
NC
я так понимаю, что вы планируете использовать orm?
Да, и вот хочу узнать сильно ли ORM медленней
A
It depends
D
Вопрос по JWT токенам:
Есть проект, два ключевых интерфейса в части авторизации - login и refresh, login взамен на имя/пароль отдает два токена - access и refresh, токены создаются абсолютно одинаково, разница лишь во времени жизни. По истечении времени access токена по классической схеме отправляется refresh и взамен присылается новый access.
1. В этой схеме можно взять refresh токен после истечения access и просто логиниться по нему, это нормально вообще?
2. В интернет статьях о JWT говорится что идея безопасности в том, чтобы можно было токен отозвать, если узнал что он украден, но в существующей у меня реализации я никак его не отзову, потому что он создается и никакой информации о нем не запоминается. (и по некоторым статьям это правильно, потому что jwt - stateless)
3. Я не понимаю вообще где безопасность в этой схеме, украв один из токенов можно какое-то время свободно получать доступ к сервису не вызывая подозрений.
Как сделать это православно, может кто вкратце описать или дать ссылку на хорошее описание?
Есть проект, два ключевых интерфейса в части авторизации - login и refresh, login взамен на имя/пароль отдает два токена - access и refresh, токены создаются абсолютно одинаково, разница лишь во времени жизни. По истечении времени access токена по классической схеме отправляется refresh и взамен присылается новый access.
1. В этой схеме можно взять refresh токен после истечения access и просто логиниться по нему, это нормально вообще?
2. В интернет статьях о JWT говорится что идея безопасности в том, чтобы можно было токен отозвать, если узнал что он украден, но в существующей у меня реализации я никак его не отзову, потому что он создается и никакой информации о нем не запоминается. (и по некоторым статьям это правильно, потому что jwt - stateless)
3. Я не понимаю вообще где безопасность в этой схеме, украв один из токенов можно какое-то время свободно получать доступ к сервису не вызывая подозрений.
Как сделать это православно, может кто вкратце описать или дать ссылку на хорошее описание?
NC
это вопросы с собеседования чтоли?
Нет, в институте курсач дали сделать на Maven + Faces + EE + glassfish, а с JAVA я вообще никак не знаком, вот и собираю базу))
NC
Думаю забить и сделать на Spring, мануалов больше в интернете
D
Нет, в институте курсач дали сделать на Maven + Faces + EE + glassfish, а с JAVA я вообще никак не знаком, вот и собираю базу))
прикольно, ты не знаком с Java, но тебе дали махровый энтерпрайз стэк
NC
прикольно, ты не знаком с Java, но тебе дали махровый энтерпрайз стэк
Образование в России би лайк))
Я говорю преподу, что на своём основном языке за 15 минут сделаю сам проект и ещё за пару дней курсовую, но он ни в какую
Я говорю преподу, что на своём основном языке за 15 минут сделаю сам проект и ещё за пару дней курсовую, но он ни в какую
NC
Извините за оффтоп
А
Вопрос по JWT токенам:
Есть проект, два ключевых интерфейса в части авторизации - login и refresh, login взамен на имя/пароль отдает два токена - access и refresh, токены создаются абсолютно одинаково, разница лишь во времени жизни. По истечении времени access токена по классической схеме отправляется refresh и взамен присылается новый access.
1. В этой схеме можно взять refresh токен после истечения access и просто логиниться по нему, это нормально вообще?
2. В интернет статьях о JWT говорится что идея безопасности в том, чтобы можно было токен отозвать, если узнал что он украден, но в существующей у меня реализации я никак его не отзову, потому что он создается и никакой информации о нем не запоминается. (и по некоторым статьям это правильно, потому что jwt - stateless)
3. Я не понимаю вообще где безопасность в этой схеме, украв один из токенов можно какое-то время свободно получать доступ к сервису не вызывая подозрений.
Как сделать это православно, может кто вкратце описать или дать ссылку на хорошее описание?
Есть проект, два ключевых интерфейса в части авторизации - login и refresh, login взамен на имя/пароль отдает два токена - access и refresh, токены создаются абсолютно одинаково, разница лишь во времени жизни. По истечении времени access токена по классической схеме отправляется refresh и взамен присылается новый access.
1. В этой схеме можно взять refresh токен после истечения access и просто логиниться по нему, это нормально вообще?
2. В интернет статьях о JWT говорится что идея безопасности в том, чтобы можно было токен отозвать, если узнал что он украден, но в существующей у меня реализации я никак его не отзову, потому что он создается и никакой информации о нем не запоминается. (и по некоторым статьям это правильно, потому что jwt - stateless)
3. Я не понимаю вообще где безопасность в этой схеме, украв один из токенов можно какое-то время свободно получать доступ к сервису не вызывая подозрений.
Как сделать это православно, может кто вкратце описать или дать ссылку на хорошее описание?
refresh нужен, что бы обновлять короткоживущий access token
DP
Вопрос по JWT токенам:
Есть проект, два ключевых интерфейса в части авторизации - login и refresh, login взамен на имя/пароль отдает два токена - access и refresh, токены создаются абсолютно одинаково, разница лишь во времени жизни. По истечении времени access токена по классической схеме отправляется refresh и взамен присылается новый access.
1. В этой схеме можно взять refresh токен после истечения access и просто логиниться по нему, это нормально вообще?
2. В интернет статьях о JWT говорится что идея безопасности в том, чтобы можно было токен отозвать, если узнал что он украден, но в существующей у меня реализации я никак его не отзову, потому что он создается и никакой информации о нем не запоминается. (и по некоторым статьям это правильно, потому что jwt - stateless)
3. Я не понимаю вообще где безопасность в этой схеме, украв один из токенов можно какое-то время свободно получать доступ к сервису не вызывая подозрений.
Как сделать это православно, может кто вкратце описать или дать ссылку на хорошее описание?
Есть проект, два ключевых интерфейса в части авторизации - login и refresh, login взамен на имя/пароль отдает два токена - access и refresh, токены создаются абсолютно одинаково, разница лишь во времени жизни. По истечении времени access токена по классической схеме отправляется refresh и взамен присылается новый access.
1. В этой схеме можно взять refresh токен после истечения access и просто логиниться по нему, это нормально вообще?
2. В интернет статьях о JWT говорится что идея безопасности в том, чтобы можно было токен отозвать, если узнал что он украден, но в существующей у меня реализации я никак его не отзову, потому что он создается и никакой информации о нем не запоминается. (и по некоторым статьям это правильно, потому что jwt - stateless)
3. Я не понимаю вообще где безопасность в этой схеме, украв один из токенов можно какое-то время свободно получать доступ к сервису не вызывая подозрений.
Как сделать это православно, может кто вкратце описать или дать ссылку на хорошее описание?
1. акцесс и рефреш токен отличаются скопом. По рефреш токену нельзя ничего сделать, кроме получения акцесс токена.
2. поверх jwt нужно самому реализовывать механизмы отзыва, используя какой-либо сторедж
2. поверх jwt нужно самому реализовывать механизмы отзыва, используя какой-либо сторедж
А
1. акцесс и рефреш токен отличаются скопом. По рефреш токену нельзя ничего сделать, кроме получения акцесс токена.
2. поверх jwt нужно самому реализовывать механизмы отзыва, используя какой-либо сторедж
2. поверх jwt нужно самому реализовывать механизмы отзыва, используя какой-либо сторедж
и 3. Украв access token действительно можно незаметно получать доступ к сервису пока токен валиден, фишка в том, что бы минимизировать потери путем уменьшения времени жизни токена
AF
Всем привет!
Вопрос на тему архитектуры интеграции - не могу разобраться как сделать правильно.
Задачи:
-Сделать витрину каких-то товаров, забирая данные у внешнего сервиса
-Вести учет изменения цен, остатков и пр. технических полей
Проблемы:
-Не понятно как мэнэджить измененные объекты и на какой стороне это лучше сделать (есть возможность попросить доработаться внешнюю систему). Выходит надо писать какой-то огромный код на то чтобы сравнивать отдельно каждое поле с тем что есть и т.д.
Ограничения:
-Инициатором запроса может быть только наша система, принимать мы ничего не можем.
-Очередей нет
-Код должен быть синхронным
Вопрос на тему архитектуры интеграции - не могу разобраться как сделать правильно.
Задачи:
-Сделать витрину каких-то товаров, забирая данные у внешнего сервиса
-Вести учет изменения цен, остатков и пр. технических полей
Проблемы:
-Не понятно как мэнэджить измененные объекты и на какой стороне это лучше сделать (есть возможность попросить доработаться внешнюю систему). Выходит надо писать какой-то огромный код на то чтобы сравнивать отдельно каждое поле с тем что есть и т.д.
Ограничения:
-Инициатором запроса может быть только наша система, принимать мы ничего не можем.
-Очередей нет
-Код должен быть синхронным