При этом интервьюер копался в этой системе годами, а кандидат должен за час не зная ничего все успеть, не нарушить тайминг, не упустить нужные детали и прочее. Это действо кроме как порнографией не назовешь.
У нас ревью не отнимает много времени. Обычно мне(лиду) пишут, просят проверить, я сразу смотрю и пропускаю, либо пишу замечания. Если я не могу, либо нужно, чтобы посмотрели и другие заинтересованные разработчики, пишется сообщение в соответствующий чат. Если срочности нет, то вообще не пишется, в течение дня будет проверено. Два дня ничего не висит. Проверять могут все, ограничений по уровням грейда проверяющих мы не устанавливали. Вдумчиво вчитываться, в основном, приходится, когда разработчик менее опытный(доверия меньше)и реквест очень большой. Тогда, обычно, и замечаний много и времени на просмотр тоже. По соотношению - в основном замечания пишутся на организацию кода(разделение на классы, методы, дублирование, паттерны и т.д.). Либо ошибки при использовании фреймворков. На линтовку замечания единичные, обычно все выдерживают примерный стиль, править его приходится крайне редко. Это при том, что линтера на java у нас не установлено, достаточно того, как помогает ide. Польза от этих мероприятий, однозначно, есть. Качество кода прилично подросло с того момента, когда ревью не было, разработчики не тащат дрянь в зависимости, соблюдают архитектурные требования, даже стажеры пишут нормальный понятный код(после кучи замечаний). Команда больше в курсе, кто что разрабатывает и как это организовано. Баги на ревью ловятся крайне редко, ответственность за них больше на исполнителях.
Нанимать человека за активность где то вне рабочей обстановки, а уж тем более хантить - очень недальновидно и рискованно. Это могло быть актуально лет пять назад, когда был расцвет отрасли и спецов не хватало, с текущим рынком точно нет. Отбор закручен по полной, претендентов навалом на любой грейд.
А кто дает публичный ключ микросервисам, чтобы проверить токен? Публичный ключ либо грузится по ресту, а затем кэшируется, либо присылается в хидере вместе с токеном, что небезопасно, т.к. можно слать любые токены от любого рандомного издателя и одабривать любые операции. Я веду к тому, что знать о сервисе аутентификации все таки придется. Или есть какая то другая схема?
На самом деле даже подпись проверить можно прямо на сервисах. Достаточно из сервиса аутентификации забрать публичный ключ от ключевой пары, подписывающей jwt. Если сервис распарсил токен, значит его подпись верна и сроки тоже(если писать на java). А роли и пермиссии обычно храним прямо в токене. То есть, выходит, в сервис аутентификации каждый раз ходить не надо. Только проверяющий сервис раз ходит за публичным ключом и его кэширует.
Может немного не по теме, встречался с интересной системой аутентификации в PlatformV IAM. Там фронт хранит только идентификатор сессии в куке, доступов к jwt у него нет. Все запросы с фронта идут через IAM (он же proxy). Тот проверяет сессию и обогащает запрос токеном из keycloak. Если сессии нет, то перенаправляет пользователя на страницу аутентификации. Если токен протух, сам обновляет. На целевые сервисы запрос приходит с access токеном в хидере(Bearer), проверка происходит на месте при помощи публичного ключа. Есть ли у кого мнения или опыт по использованию такой гибридной схемы?
JWT был придуман для легковесной stateless аутентификации по месту требования. Если поставщик верифицирован (по публичному ключу) и сроки валидны, то мы доверяем поставщику токена и разрешаем операцию. Если же проверять токен где-то отдельно на основе сессий, то вся легковесность и stateless исчезает вместе со смыслом самого JWT.
Не ясно до конца, где находится страница логина, на клиенте или спринг ее отдает? Кто ответственен за обновление jwt? Фронтенд?
Тема с корсом не должна настраиваться, она разрешается относительными урлами и маршрутизацией на уровне инфраструктуры.
Как вижу, этот сервер и генерирует jwt и сам же их проверяет, что, по мне, не очень хорошо, если архитектура сервисная. Там генерация идет в keycloak, к примеру, а проверять токен может любой сервис, имеющий публичный ключ. К примеру api gateway.
Тема с двухфазной аутентификацией(сессия в куке + пара jwt очень интересна, имел дело с подобной схемой в сберовском iam proxy. Там также своя страница аутентификации, настройки маршрутизации. Любой запрос проходит через iam до сервисов доходит уже с jwt. В статье все роли обьединены в одном сервисе, как это грамотно растащить и натянуть на оркестратор контейнеров - отдельная задача.
Попробую себе утащить алгоритмы генерации и обновления jwt. Очень хорошая замена относительно тяжеловесному кейклоку.
Тут то же самое. Брошенная учеба в вышке, потом в работе тоже все по наклонной. Скатилось до работы грузчиком, комп не освоен даже до уровня включить выключить. Но, при этом, куча рассказов, как будет сделано, но по факту ничего. Наследственность у меня такая. И у отца есть и у сына проявилось.
Сделать уроки, сделать дела перед сном, просто убраться. Сделать что то вовремя. Сделать любое дело, если там надо прилагать усилия, стараться и решение еще не знакомо.
100 грамм тортика это совсем чуток, но киллокалорий аж 400 штук, что эквивалентно примерно 5 км бега. В этих вопросах легче заменить мучное и сладкое более легкими аналогами и результат будет достаточно неплохим.
Это все хорошо. Но такие задачи реально решаются так: день пыжишься, что то ищешь, три дня играешь в шахматы слегка выгорев, затем решение приходит в голову где нибудь на прогулке. Как оценить результат такой деятельности - большой вопрос, потому как большую часть времени просто не работал.
А каким образом фиксируются доказательства наличия утечки? Сми могут соврать, оклеветать и т.д. Утечка может быть, но не у подозреваемого юрлица. Есть ли какие то способы работы в этом направлении? Соблюдать абсолютно все законы - хорошо (наверное), но так и без штанов остаться недолго.
Если оставляют прозябать, значит так им и надо. Не просто же так это происходит.
При этом интервьюер копался в этой системе годами, а кандидат должен за час не зная ничего все успеть, не нарушить тайминг, не упустить нужные детали и прочее. Это действо кроме как порнографией не назовешь.
У нас ревью не отнимает много времени. Обычно мне(лиду) пишут, просят проверить, я сразу смотрю и пропускаю, либо пишу замечания. Если я не могу, либо нужно, чтобы посмотрели и другие заинтересованные разработчики, пишется сообщение в соответствующий чат. Если срочности нет, то вообще не пишется, в течение дня будет проверено. Два дня ничего не висит. Проверять могут все, ограничений по уровням грейда проверяющих мы не устанавливали. Вдумчиво вчитываться, в основном, приходится, когда разработчик менее опытный(доверия меньше)и реквест очень большой. Тогда, обычно, и замечаний много и времени на просмотр тоже. По соотношению - в основном замечания пишутся на организацию кода(разделение на классы, методы, дублирование, паттерны и т.д.). Либо ошибки при использовании фреймворков. На линтовку замечания единичные, обычно все выдерживают примерный стиль, править его приходится крайне редко. Это при том, что линтера на java у нас не установлено, достаточно того, как помогает ide. Польза от этих мероприятий, однозначно, есть. Качество кода прилично подросло с того момента, когда ревью не было, разработчики не тащат дрянь в зависимости, соблюдают архитектурные требования, даже стажеры пишут нормальный понятный код(после кучи замечаний). Команда больше в курсе, кто что разрабатывает и как это организовано. Баги на ревью ловятся крайне редко, ответственность за них больше на исполнителях.
Скорее всего не сильно больше чем у тех, кто развозит еду и товары по Москве.
Нанимать человека за активность где то вне рабочей обстановки, а уж тем более хантить - очень недальновидно и рискованно. Это могло быть актуально лет пять назад, когда был расцвет отрасли и спецов не хватало, с текущим рынком точно нет. Отбор закручен по полной, претендентов навалом на любой грейд.
А кто дает публичный ключ микросервисам, чтобы проверить токен? Публичный ключ либо грузится по ресту, а затем кэшируется, либо присылается в хидере вместе с токеном, что небезопасно, т.к. можно слать любые токены от любого рандомного издателя и одабривать любые операции. Я веду к тому, что знать о сервисе аутентификации все таки придется. Или есть какая то другая схема?
На самом деле даже подпись проверить можно прямо на сервисах. Достаточно из сервиса аутентификации забрать публичный ключ от ключевой пары, подписывающей jwt. Если сервис распарсил токен, значит его подпись верна и сроки тоже(если писать на java). А роли и пермиссии обычно храним прямо в токене. То есть, выходит, в сервис аутентификации каждый раз ходить не надо. Только проверяющий сервис раз ходит за публичным ключом и его кэширует.
Может немного не по теме, встречался с интересной системой аутентификации в PlatformV IAM. Там фронт хранит только идентификатор сессии в куке, доступов к jwt у него нет. Все запросы с фронта идут через IAM (он же proxy). Тот проверяет сессию и обогащает запрос токеном из keycloak. Если сессии нет, то перенаправляет пользователя на страницу аутентификации. Если токен протух, сам обновляет. На целевые сервисы запрос приходит с access токеном в хидере(Bearer), проверка происходит на месте при помощи публичного ключа. Есть ли у кого мнения или опыт по использованию такой гибридной схемы?
JWT был придуман для легковесной stateless аутентификации по месту требования. Если поставщик верифицирован (по публичному ключу) и сроки валидны, то мы доверяем поставщику токена и разрешаем операцию. Если же проверять токен где-то отдельно на основе сессий, то вся легковесность и stateless исчезает вместе со смыслом самого JWT.
Не ясно до конца, где находится страница логина, на клиенте или спринг ее отдает? Кто ответственен за обновление jwt? Фронтенд?
Тема с корсом не должна настраиваться, она разрешается относительными урлами и маршрутизацией на уровне инфраструктуры.
Как вижу, этот сервер и генерирует jwt и сам же их проверяет, что, по мне, не очень хорошо, если архитектура сервисная. Там генерация идет в keycloak, к примеру, а проверять токен может любой сервис, имеющий публичный ключ. К примеру api gateway.
Тема с двухфазной аутентификацией(сессия в куке + пара jwt очень интересна, имел дело с подобной схемой в сберовском iam proxy. Там также своя страница аутентификации, настройки маршрутизации. Любой запрос проходит через iam до сервисов доходит уже с jwt. В статье все роли обьединены в одном сервисе, как это грамотно растащить и натянуть на оркестратор контейнеров - отдельная задача.
Попробую себе утащить алгоритмы генерации и обновления jwt. Очень хорошая замена относительно тяжеловесному кейклоку.
Спасибо за статью!
Тут то же самое. Брошенная учеба в вышке, потом в работе тоже все по наклонной. Скатилось до работы грузчиком, комп не освоен даже до уровня включить выключить. Но, при этом, куча рассказов, как будет сделано, но по факту ничего. Наследственность у меня такая. И у отца есть и у сына проявилось.
Сделать уроки, сделать дела перед сном, просто убраться. Сделать что то вовремя. Сделать любое дело, если там надо прилагать усилия, стараться и решение еще не знакомо.
Насчет мотивации поспорю. С РАС, зачастую, это проблема, причем серьезная.
С такими обычно проще, испытательный срок заканчивается досрочно и приходит другой, более мотивированный джун.
100 грамм тортика это совсем чуток, но киллокалорий аж 400 штук, что эквивалентно примерно 5 км бега. В этих вопросах легче заменить мучное и сладкое более легкими аналогами и результат будет достаточно неплохим.
Это все хорошо. Но такие задачи реально решаются так: день пыжишься, что то ищешь, три дня играешь в шахматы слегка выгорев, затем решение приходит в голову где нибудь на прогулке. Как оценить результат такой деятельности - большой вопрос, потому как большую часть времени просто не работал.
HR не решают, сколько денег будут платить. Это решает менеджмент, причем, зачастую, высший. HR только исполняет.
Очень приличный результат! Особенно с учетом весовой.
А каким образом фиксируются доказательства наличия утечки? Сми могут соврать, оклеветать и т.д. Утечка может быть, но не у подозреваемого юрлица. Есть ли какие то способы работы в этом направлении? Соблюдать абсолютно все законы - хорошо (наверное), но так и без штанов остаться недолго.
Эх. А я меня в последнее время, наоборот, драйвит тяжелая атлетика. Разработка, при этом, каких то эмоций не несет. Какая сумма была в троеборье?