Хм, нормальный процесс разработки любого софта. В коментах как всегда на менеджеров всех собак спускают, но любой софт это компромис между качеством и сроками. Уже давно никто не пилит до совершенства, иногда лучше выкатить как есть, собрать фидбек, и потом итеративно улучшать.
SAML, Open ID Connect не слышали? Лепить свой велосипед нужно только когда есть необходимость. Ещё есть стандартные названия Identity Provider (ваш SSO сервер) и Service Provider (ваш SSO consumer). Кроме того аббревиатура SSO — это очень широкое понятие и неплохо бы сразу объяснить как технически вы собрались это реализовывать, в вашем случае это своя какая-то реализация котловая похожа на SAML по принципу действия. Кроме того зачастую токен с данными о пользователе можно сразу передавать без необходимости сервис-провайдеру делать дополнительный запрос айденти провайдеру (это дополнительные сложности).
Ну если клиенты ленятся генерировать свой приватный ключ и подписывать сертификаты через CSR, то в общем то сами они навлекли на себя проблемы.
Ну а вообще конечно непонятно нахрен они вообще хранят эти ключи — ну сгенерировали ленивому клиенту, дали скачать и удаляй нахрен. Лишний головняк только.
Я может что-то не догоняю… А какая проблема с передачей хэша? То что его можно сбрутфорсить? Насколько я понимаю это только будет иметь смысл если точно знать пользователя, от какого сервиса пароль, и какой логин-нэйм.
Непонятно, отчего так много негатива в комментариях. Ну и пусть немного хайп, зато в деле проверят технологию, посмотрят вообще имеет смысл или нет, тестирование в реальных условиях все равно нужно. В комментариях выше приводят NoSQL как пример подобного хайпа который всюду пытались всунуть, зато всем стало понятно что NoSQL не панацея от всех проблем, но подходит для некоторых задач хорошо — теперь благодаря этому люди делают осмысленный выбор. Также и с блокчейном будет.
Глянул на Prepack — чтобы от него была польза сначала нужно написать какой-то говенный код, а потом пропустить через Prepack (disclaimer — React is good).
Ну вот, опять на неделю чтива! Как всегда огромное спасибо. И вообще мне кажется что за последние месяцы стало больше интересных статей по фронтенду — у людей появилось больше понимание, больше новых мыслей о том как «должно быть».
Вспомнилось о фильме «Довод»
Хм, нормальный процесс разработки любого софта. В коментах как всегда на менеджеров всех собак спускают, но любой софт это компромис между качеством и сроками. Уже давно никто не пилит до совершенства, иногда лучше выкатить как есть, собрать фидбек, и потом итеративно улучшать.
1 секунда?
SAML, Open ID Connect не слышали? Лепить свой велосипед нужно только когда есть необходимость. Ещё есть стандартные названия Identity Provider (ваш SSO сервер) и Service Provider (ваш SSO consumer). Кроме того аббревиатура SSO — это очень широкое понятие и неплохо бы сразу объяснить как технически вы собрались это реализовывать, в вашем случае это своя какая-то реализация котловая похожа на SAML по принципу действия. Кроме того зачастую токен с данными о пользователе можно сразу передавать без необходимости сервис-провайдеру делать дополнительный запрос айденти провайдеру (это дополнительные сложности).
Wondering about s it’s application in evtols. Sounds like it would suit very well
Ну если клиенты ленятся генерировать свой приватный ключ и подписывать сертификаты через CSR, то в общем то сами они навлекли на себя проблемы.
Ну а вообще конечно непонятно нахрен они вообще хранят эти ключи — ну сгенерировали ленивому клиенту, дали скачать и удаляй нахрен. Лишний головняк только.