> дороговато выходит, дешевле всё-таки code review. Обычно так говорят, когда не считают: - стоимость задержек и ожиданий - стоимость переделок (чем позже, тем дороже) - стоимость хорошего код-ревью (не просто поскроллить дифф, а пойти узнать, что за задача, и разобраться, почему она была решена именно так).
И когда не разбираются в том, как устроено обучение, и почему code reivew в большинстве случаев - не оно :)
Сделайте лендинг, прикиньтесь центром сертификации SOSAL, глядишь, кто-нибудь с ликендина и зацепится. Может, даже спросят, как сертифицироваться. С govno.works так и случилось :)
Вы правы, автор тут не слишком формален. Под обычной сессией он подразумевает действительно идентификатор, по которому на сервере можно будет найти эти данные.
От stateful jwt это действительно мало чем отличается (что автор в тексте отметил), кроме того, что фреймворк (или библиотеки) зачастую дают эту цепочку как готовую ("получить идентификатор - подписать его - оформить в виде куки") либо делают за вас часть этой цепочки в виде подписи. И тогда вопрос целесообразности. Если уже есть готовый способ получить идентификатор сессии и подписать его через HMAC, то зачем тогда JWT? При этом верно и обратное, если библиотека оперирует jwt изначально (как jjwt, например), то можно и его использовать, это ничему не противоречит.
Основной поинт в том, чтобы не превращать этот токен в хранилище.
В целом - да, удачное резюме. Тем не менее, до сих с какой-то периодичностью я слышу эти же самые аргументы в пользу отказа от серверных сессий в пользу вшивания данных в JWT, и даже такой уровень рассмотрения помогает людям прийти в себя и посмотреть на альтернативы. Ну а раз это уже кому-то помогло, может, и еще кому поможет? :)
Автор специально для вас проводит целое рассуждение, а вы споткнулись о первую фразу. Поднимитесь, отряхнитесь и дочитайте комментарий.
> дороговато выходит, дешевле всё-таки code review.
Обычно так говорят, когда не считают:
- стоимость задержек и ожиданий
- стоимость переделок (чем позже, тем дороже)
- стоимость хорошего код-ревью (не просто поскроллить дифф, а пойти узнать, что за задача, и разобраться, почему она была решена именно так).
И когда не разбираются в том, как устроено обучение, и почему code reivew в большинстве случаев - не оно :)
Сделайте лендинг, прикиньтесь центром сертификации SOSAL, глядишь, кто-нибудь с ликендина и зацепится. Может, даже спросят, как сертифицироваться. С govno.works так и случилось :)
Вы правы, автор тут не слишком формален. Под обычной сессией он подразумевает действительно идентификатор, по которому на сервере можно будет найти эти данные.
От stateful jwt это действительно мало чем отличается (что автор в тексте отметил), кроме того, что фреймворк (или библиотеки) зачастую дают эту цепочку как готовую ("получить идентификатор - подписать его - оформить в виде куки") либо делают за вас часть этой цепочки в виде подписи.
И тогда вопрос целесообразности. Если уже есть готовый способ получить идентификатор сессии и подписать его через HMAC, то зачем тогда JWT?
При этом верно и обратное, если библиотека оперирует jwt изначально (как
jjwt, например), то можно и его использовать, это ничему не противоречит.Основной поинт в том, чтобы не превращать этот токен в хранилище.
В целом - да, удачное резюме.
Тем не менее, до сих с какой-то периодичностью я слышу эти же самые аргументы в пользу отказа от серверных сессий в пользу вшивания данных в JWT, и даже такой уровень рассмотрения помогает людям прийти в себя и посмотреть на альтернативы.
Ну а раз это уже кому-то помогло, может, и еще кому поможет? :)