Что такое JWT вы можете загуглить.
Объясню что меня удивляет в ваших ответах:
1. Вы пишете:
Минус лишь в том что при каждом получении access токена идет запрос в базу.
Т. е. логично предположить что при обычном запросе вы к базе не обращаетесь. И это правильно. От части это преимущество использования JWT. Но в то же время вы пишете:
Убил в базе refresh, новый access не получишь и все access выписанные c этим refresh тоже не работают.
Получается что вы всеравно каждый раз лезете в базу чтобы достать оттуда refresh токен для проверки access токена.
2. При использовании JWT refresh токен используется для выдачи нового токена, а для валидации access токена он не требуется, так как там сверяется сигнатура. Исходя из ваших слов — у вас не так.
3. При использовании JWT refresh токен является ОДНОРАЗОВЫМ. И его нужно беречь еще больше чем access токен, так как даже если у вас украдут только access токен, то пользоваться им смогут только пока он не устареет (обычно минут 15, а в вашем случае всего 2 месяца). А если украдут оба токена, то пользоваться ими смогут бесконечно.
4. Вы пишете:
Отправил пользователь 5ть запросов параллельно получил 5ть access токенов, если они в запросе не валидны.
Итак пришел первый запрос. Сервер формирует новый access (у вас refresh) токен — старый стирает. Получается что остальные запросы со старыми токенами должны быть невалидными так как в них зашит старый refresh токен. Каким образом получается что у вас они всеравно получат новые токены?
Я храню в localStorage или в куках — по разному.
Я не говорю что вы сделали что-то ужасное. Просто почему бы вам вообще не отказаться от refresh токена? Пусть будет только access и все.
Вот тогда у вас действительно не будет заморочек. А сейчас получается у вас возможен такой вариант:
1. Клиент отправит на сервер несколько запросов одновременно с устаревшим токеном
2. В запросе, который дойдет до сервера первым — будет заменен токен
3. Все остальные запросы будут отклонены, так как в них токен еще старый (истекший и с уже невалидным refresh токеном)
Во первых не в блокнот. И упепеть его могут, но не так легко как access token.
Во вторых можно и без рефреш токена, но его тогда можно просто не обновлять. Зачем зашивать его в access?
Ну а отпечаток это хорошо и правильно, но к моему вопросу не относится.
Чтоооо??? 0_о Зачем он тогда вообще вам нужен? Refresh token нужен для повышения безопасности если украден access token. А у вас получается что если украли access token, то украли и refresh token.
1. Понял. Спасибо.
2. Насколько я понимаю это избавляет от проблем с разными часовыми поясами, но если на устройстве часы просто отстают, тогда же NumericDate на устройстве будет меньше чем на сервере?! Хотя синхронизацию времени наверное тоже надо оставить на совести пользователя.
3. Спасибо. Я тоже пришел к такому варианту. Или же каждый раз брать токен из localStorage. Интересно было как вы это решили.
4. Четвертый вопрос я дописал позже, и вы на него не ответили. )
Извиняюсь, но мой английский еще не настолько хорош, чтобы грамотно сформулировать этот вопрос, поэтому я спрошу на русском.
Спасибо за статью. Я тоже долгое время занимался данной задачей.
Скажите что вы делаете в следующих случаях:
1. Что происходит когда токен становится невалидным и его обновление проходит неудачно?
2. Что если время на устройстве пользователя не совпадает с временем на сервере? Ведь тогда isExpired() может работать не корректно.
3. Как быть если сайт открыт в двух вкладках одновременно и на одной из них токен обновился, а на другой нет? Ведь метод getToken() не проверяет наличие нового токена в localStorage.
4. Что если при истекшем токене несколько запросов посылаются одновременно? Т. е. в этом случае для каждого из запросов isExpired() вернет false и для запустится обновление токена.
Что-то я вас не понимаю.
Если вы хотите сделать билд отдельного компонента, то точкой входа будет файл .vue. Такой компонент вы сможете подключить на страницу и использовать во Vue-приложении.
Если же вы хотите билд готового приложения, то используете как точку входа main.js. Полученный файл вы подключите к странице и он все сделает сам.
Да, но вы вводите людей в заблуждение в статье. А если вы захотите "инициализировать приложения в определенном месте или после какого-то действия", то вам уже не IIFE нужна. Ну а если вебпак это сделает, то нам не надо делать это еще и самим. Прием безусловно хороший, но тут он не нужен.
Ок. Тогда советую вам использовать Vue CLI если вы еще этого не делаете, у него есть возможность делать сборки отдельных компонентов, можно даже в виде веб-компонентов.
И еще исправьте, пожалуйста:
Но в таком случае код сам по себе не выполнится...
Выполнится, так как этот код уже вызывает функцию, а вы ее зачем-то заворачиваете в другую функцию и вызываете уже ее.
Прочитав статью, я так и не понял:
1. Что может дать внедрение frontend-фреймворков в решения на sitefinity?
2. Почему вы решили использовать именно Vue?
Ну и вообще я считаю что данные способы требуют доработки, как минимум. Вы используете это в production?
Не думаю, что события порожденные ядром для каждого компонента в вашем приложении не рекомендуются к использованию
Конечно вы можете их использовать, но разработчики оставляют за собой право в любой момент убрать их, переименовать или изменить логику их работы. Это конечно не критично, но надо об этом помнить. Подобных «скрытых» возможностей во Vue много и Эван сам писал что лучше воздержаться от использования их в коде. Например вот он пишет про использование _uid.
ну и из приведенного вами пункта документации можно, вывести что компонент порождает событие hook: имя_хука_жизненного_цикла, но вот о том что его можно подслушать на компоненте, увы не сказано
1. Компонент порождает события «hook:».
2. События компонента можно слушать.
Неужели вам надо сказать это еще более явно? )
А вообще то — чего нет в документации — это обычно возможности, которые не рекомендуется использовать, потому что они могут исчезнуть или измениться в очередной версии.
Почему "капибара", а не "капибу"? )
Объясню что меня удивляет в ваших ответах:
1. Вы пишете:
Т. е. логично предположить что при обычном запросе вы к базе не обращаетесь. И это правильно. От части это преимущество использования JWT. Но в то же время вы пишете:
Получается что вы всеравно каждый раз лезете в базу чтобы достать оттуда refresh токен для проверки access токена.
2. При использовании JWT refresh токен используется для выдачи нового токена, а для валидации access токена он не требуется, так как там сверяется сигнатура. Исходя из ваших слов — у вас не так.
3. При использовании JWT refresh токен является ОДНОРАЗОВЫМ. И его нужно беречь еще больше чем access токен, так как даже если у вас украдут только access токен, то пользоваться им смогут только пока он не устареет (обычно минут 15, а в вашем случае всего 2 месяца). А если украдут оба токена, то пользоваться ими смогут бесконечно.
4. Вы пишете:
Итак пришел первый запрос. Сервер формирует новый access (у вас refresh) токен — старый стирает. Получается что остальные запросы со старыми токенами должны быть невалидными так как в них зашит старый refresh токен. Каким образом получается что у вас они всеравно получат новые токены?
Я не говорю что вы сделали что-то ужасное. Просто почему бы вам вообще не отказаться от refresh токена? Пусть будет только access и все.
Вот тогда у вас действительно не будет заморочек. А сейчас получается у вас возможен такой вариант:
1. Клиент отправит на сервер несколько запросов одновременно с устаревшим токеном
2. В запросе, который дойдет до сервера первым — будет заменен токен
3. Все остальные запросы будут отклонены, так как в них токен еще старый (истекший и с уже невалидным refresh токеном)
Во первых не в блокнот. И упепеть его могут, но не так легко как access token.
Во вторых можно и без рефреш токена, но его тогда можно просто не обновлять. Зачем зашивать его в access?
Ну а отпечаток это хорошо и правильно, но к моему вопросу не относится.
2. Насколько я понимаю это избавляет от проблем с разными часовыми поясами, но если на устройстве часы просто отстают, тогда же NumericDate на устройстве будет меньше чем на сервере?! Хотя синхронизацию времени наверное тоже надо оставить на совести пользователя.
3. Спасибо. Я тоже пришел к такому варианту. Или же каждый раз брать токен из localStorage. Интересно было как вы это решили.
4. Четвертый вопрос я дописал позже, и вы на него не ответили. )
Спасибо за статью. Я тоже долгое время занимался данной задачей.
Скажите что вы делаете в следующих случаях:
1. Что происходит когда токен становится невалидным и его обновление проходит неудачно?
2. Что если время на устройстве пользователя не совпадает с временем на сервере? Ведь тогда isExpired() может работать не корректно.
3. Как быть если сайт открыт в двух вкладках одновременно и на одной из них токен обновился, а на другой нет? Ведь метод getToken() не проверяет наличие нового токена в localStorage.
4. Что если при истекшем токене несколько запросов посылаются одновременно? Т. е. в этом случае для каждого из запросов isExpired() вернет false и для запустится обновление токена.
Если вы хотите сделать билд отдельного компонента, то точкой входа будет файл .vue. Такой компонент вы сможете подключить на страницу и использовать во Vue-приложении.
Если же вы хотите билд готового приложения, то используете как точку входа main.js. Полученный файл вы подключите к странице и он все сделает сам.
Да, но вы вводите людей в заблуждение в статье. А если вы захотите "инициализировать приложения в определенном месте или после какого-то действия", то вам уже не IIFE нужна. Ну а если вебпак это сделает, то нам не надо делать это еще и самим. Прием безусловно хороший, но тут он не нужен.
Если использовать режим сборки библиотеки и в качестве точки входа указать .vue файл, то чем это не отдельный компонент?
И еще исправьте, пожалуйста:
Выполнится, так как этот код уже вызывает функцию, а вы ее зачем-то заворачиваете в другую функцию и вызываете уже ее.
1. Что может дать внедрение frontend-фреймворков в решения на sitefinity?
2. Почему вы решили использовать именно Vue?
Ну и вообще я считаю что данные способы требуют доработки, как минимум. Вы используете это в production?
Конечно вы можете их использовать, но разработчики оставляют за собой право в любой момент убрать их, переименовать или изменить логику их работы. Это конечно не критично, но надо об этом помнить. Подобных «скрытых» возможностей во Vue много и Эван сам писал что лучше воздержаться от использования их в коде. Например вот он пишет про использование _uid.
1. Компонент порождает события «hook:».
2. События компонента можно слушать.
Неужели вам надо сказать это еще более явно? )
vuejs.org/v2/guide/components-edge-cases.html#Programmatic-Event-Listeners
А вообще то — чего нет в документации — это обычно возможности, которые не рекомендуется использовать, потому что они могут исчезнуть или измениться в очередной версии.
Уверенности в себе вам не занимать. )
ru.vuejs.org/v2/guide/render-function.html