Так все понятно. Кроме одного. Почему уволили Рика, а не менеджмент?
Это знаете как-то однобоко, все проблемы решаются за счет программеров а менеджмент во всем белом, ах, у нас не получилось, придется зачищать.
С себя зачистку пусть бы и начинали.
Или над уровнем джуниоров :-).
Если бы я решал, кого присылает наш HR отдел нам в работнички…
На самом деле проблема не в опыте и не в джуниорах. Проблема в дебилах. И опыт это чаще всего не исправляет.
Ну так это другой случай. Вы часто ходили к этому вашему звездному чуваку за техническими советами? А вот к тому Рику ходила вся команда по всем сложным вопросам. И он брался помогать и разъяснять каждому. Даже доску специально поставил.
Заметьте, не он принуждал кого-то делать так и так — к нему все сами шли.
Ну да, грузовик вовремя не заехал, пришлось чувака увольнять самим и переписывать код с нуля.
Зашибенный успех менеджмента. Кто платит за весь этот праздник щедрости?
Я все же позволю себе усомниться что качество когда было низкое. Потому что автор как раз как бы саркастически пишет: «Of course, these bugs were happening because the users had misstated their assumptions. Of course there wasn’t any problem in his work. Of course.»
О чем это говорит? О том, что предметно доказать проблемы в его коде не смогли.
Но зачем вникать? Можно ведь ерничать, вместо того чтобы попросить этого парня попросту ревьювить чужие коммиты. По большому счету, только этим его и следовало бы загружать.
По моему личному опыту, меня напрягает, когда мой код дают ревьювить человеку, профессионально ниже меня на порядок. С другой стороны, всегда интересно мнение профессионала твоего уровня или выше, когда смотришь на предложенную правку — и просто вау, я и не подумал что так просто можно все решить.
Так что еще очень большая проблема — сильная разница в уровне у членов комманды.
Тогда выское дерево будет непременно срублено. Так и получилось.
Я бы добавил, что я сильно сомневаюсь, что его код был так уж плох.
Как то у меня не складывается воедино история о «коде, полном копипасты» и чуваке — «решателе проблем», к которому вся команда ходит консультироваться.
Полностью согласен с выводами автора статьи.
На чувака вешали всю жесть, в то время как другие члены команды расслаблено занимались тем, что им интересно. Что-то сложное, что может загрузить мозг на пределы рабочего времени — для этого есть Рик. Реально, чувака загнали, а потом выкинули.
Теперь, то, что делал Рик, будет стоить компании в разы, если не на порядки дороже.
Что мешали им раньше увеличить расходы и разгрузить чувака?
Мое мнение, компания потеряла нетривиального парня. И десяток посредственностей его не заменят.
Зависит от вашего сценария.
1.Если у вас конфиденциальный клиент, то можно требовать отправки client_id и client_secret вместе с refresh token для получения нового токена доступа. Т.о. если злоумышленник не знает вашего секрета, то получить новый токен доступа он не сможет.
2. На публичном клиенте, если злоумышленник знает client_id и refresh token — то это все что ему нужно :-).
Разница в том, что это будет обращение к внутреннему хранилищу, а не к внешнему серверу авторизации.
Но, да, я согласен, это чисто теоретический и излишне параноидальный сценарий.
Я считаю, что делать токен короткоживущим достаточно. Т.к. за то время, пока вы узнаете, что токен скомпрометирован и добавите его в некий список, он уже скорее всего устареет в любом случае.
refresh token не передается сервису и т.о. он более безопасный. Компрометация refresh tokenа сама по себе еще не обязательно приведет к возможности получения злоумышленником новых токенов. Зависит от того, какой механизм используется для передачи токена клиенту.
Идея 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.
Это знаете как-то однобоко, все проблемы решаются за счет программеров а менеджмент во всем белом, ах, у нас не получилось, придется зачищать.
С себя зачистку пусть бы и начинали.
Если бы я решал, кого присылает наш HR отдел нам в работнички…
На самом деле проблема не в опыте и не в джуниорах. Проблема в дебилах. И опыт это чаще всего не исправляет.
Заметьте, не он принуждал кого-то делать так и так — к нему все сами шли.
Зашибенный успех менеджмента. Кто платит за весь этот праздник щедрости?
О чем это говорит? О том, что предметно доказать проблемы в его коде не смогли.
Но зачем вникать? Можно ведь ерничать, вместо того чтобы попросить этого парня попросту ревьювить чужие коммиты. По большому счету, только этим его и следовало бы загружать.
Так что еще очень большая проблема — сильная разница в уровне у членов комманды.
Тогда выское дерево будет непременно срублено. Так и получилось.
Как то у меня не складывается воедино история о «коде, полном копипасты» и чуваке — «решателе проблем», к которому вся команда ходит консультироваться.
На чувака вешали всю жесть, в то время как другие члены команды расслаблено занимались тем, что им интересно. Что-то сложное, что может загрузить мозг на пределы рабочего времени — для этого есть Рик. Реально, чувака загнали, а потом выкинули.
Теперь, то, что делал Рик, будет стоить компании в разы, если не на порядки дороже.
Что мешали им раньше увеличить расходы и разгрузить чувака?
Мое мнение, компания потеряла нетривиального парня. И десяток посредственностей его не заменят.
1.Если у вас конфиденциальный клиент, то можно требовать отправки client_id и client_secret вместе с refresh token для получения нового токена доступа. Т.о. если злоумышленник не знает вашего секрета, то получить новый токен доступа он не сможет.
2. На публичном клиенте, если злоумышленник знает client_id и refresh token — то это все что ему нужно :-).
Но, да, я согласен, это чисто теоретический и излишне параноидальный сценарий.
Я считаю, что делать токен короткоживущим достаточно. Т.к. за то время, пока вы узнаете, что токен скомпрометирован и добавите его в некий список, он уже скорее всего устареет в любом случае.
И как раз этот токен предназначен для того, чтобы пользователю не приходилось вводить пароль снова и снова.
Никто не мешает вам сделать JWT токен долгоживущим, если вы по какой-то странной причине считаете это нужным.
Никто не запрещает вам добавить проверку JWT токена в черном списке, как я сказал выше.
Разница и профит в том, что вам не надо напрягать сервер авторизации для такой проверки.
Но вообще говоря, короткоживущий токен рекомендуется в oAuth2 вообще и вне зависимости от механизма валидации.
К JWT это вообще отношения не имеет. Если безопасность не проблема — восстанавливайте сессии с authorisation server по куки (или еще как нибудь) невидимо для пользователя и открывайте ему сразу страницу его банковского счета, например.