ŹR
дизайн феникса мне не подходит, лол
Или тебе так кажется, что еще более лол
Size: a a a
2020 April 09
ŹR
Иногда лучше 15% кода натягивать сову на глобус, чем 100% кода писать все самому лоу-левел
ŹR
Поэтому рельсы такие сука популярные
IB
Господа, а позвольте вопрос чуть отвлеченный от непосредственно эликсира?
У нас сейчас происходит обсуждение в компании, как правильно устравивать управление пользователями и авторизацией. При этом один из руководителей очень сильно топит за идею прям отдельного контура для паролей и рефреш-токенов: мол, во-первых, минимально необходимый код, который проще отсматривать, чтобы ничего не пересекалось по зонам ответственности; во-вторых, что бы никто не имел отдельного доступа к ползовательским токенам и не мог от их имени ничего сделать.
Однако есть и вторая сторона проблемы: данные пользователей должны по идее храниться в основной БД (что как бы норм вроде бы, сервис авторизации + resource server), что бы к ним ассоциировать всякое.
Посмотрели в сторону KeyCloak в качестве готового решения — поняли, что региистрацию нужно делать "через прокси", т.е. что бы собирать больше пользовательских дданых при регистрации, а так же что бы создавать соответствующую запись в основной БД. KeyCloak требует админского доступа от приложения, что бы регистировать пользователей не через свои формы, что несколько рушит концепт изоляции.
У меня не было раньше опыта построения более сложных систем авторизации, обычно стараюсь брать для этой сферы готовое решение. У кого-то может быть есть опыт, или идеи, или готовые решения на основании которых это стоит делать?
Спасибо большое!
У нас сейчас происходит обсуждение в компании, как правильно устравивать управление пользователями и авторизацией. При этом один из руководителей очень сильно топит за идею прям отдельного контура для паролей и рефреш-токенов: мол, во-первых, минимально необходимый код, который проще отсматривать, чтобы ничего не пересекалось по зонам ответственности; во-вторых, что бы никто не имел отдельного доступа к ползовательским токенам и не мог от их имени ничего сделать.
Однако есть и вторая сторона проблемы: данные пользователей должны по идее храниться в основной БД (что как бы норм вроде бы, сервис авторизации + resource server), что бы к ним ассоциировать всякое.
Посмотрели в сторону KeyCloak в качестве готового решения — поняли, что региистрацию нужно делать "через прокси", т.е. что бы собирать больше пользовательских дданых при регистрации, а так же что бы создавать соответствующую запись в основной БД. KeyCloak требует админского доступа от приложения, что бы регистировать пользователей не через свои формы, что несколько рушит концепт изоляции.
У меня не было раньше опыта построения более сложных систем авторизации, обычно стараюсь брать для этой сферы готовое решение. У кого-то может быть есть опыт, или идеи, или готовые решения на основании которых это стоит делать?
Спасибо большое!
f
Господа, а позвольте вопрос чуть отвлеченный от непосредственно эликсира?
У нас сейчас происходит обсуждение в компании, как правильно устравивать управление пользователями и авторизацией. При этом один из руководителей очень сильно топит за идею прям отдельного контура для паролей и рефреш-токенов: мол, во-первых, минимально необходимый код, который проще отсматривать, чтобы ничего не пересекалось по зонам ответственности; во-вторых, что бы никто не имел отдельного доступа к ползовательским токенам и не мог от их имени ничего сделать.
Однако есть и вторая сторона проблемы: данные пользователей должны по идее храниться в основной БД (что как бы норм вроде бы, сервис авторизации + resource server), что бы к ним ассоциировать всякое.
Посмотрели в сторону KeyCloak в качестве готового решения — поняли, что региистрацию нужно делать "через прокси", т.е. что бы собирать больше пользовательских дданых при регистрации, а так же что бы создавать соответствующую запись в основной БД. KeyCloak требует админского доступа от приложения, что бы регистировать пользователей не через свои формы, что несколько рушит концепт изоляции.
У меня не было раньше опыта построения более сложных систем авторизации, обычно стараюсь брать для этой сферы готовое решение. У кого-то может быть есть опыт, или идеи, или готовые решения на основании которых это стоит делать?
Спасибо большое!
У нас сейчас происходит обсуждение в компании, как правильно устравивать управление пользователями и авторизацией. При этом один из руководителей очень сильно топит за идею прям отдельного контура для паролей и рефреш-токенов: мол, во-первых, минимально необходимый код, который проще отсматривать, чтобы ничего не пересекалось по зонам ответственности; во-вторых, что бы никто не имел отдельного доступа к ползовательским токенам и не мог от их имени ничего сделать.
Однако есть и вторая сторона проблемы: данные пользователей должны по идее храниться в основной БД (что как бы норм вроде бы, сервис авторизации + resource server), что бы к ним ассоциировать всякое.
Посмотрели в сторону KeyCloak в качестве готового решения — поняли, что региистрацию нужно делать "через прокси", т.е. что бы собирать больше пользовательских дданых при регистрации, а так же что бы создавать соответствующую запись в основной БД. KeyCloak требует админского доступа от приложения, что бы регистировать пользователей не через свои формы, что несколько рушит концепт изоляции.
У меня не было раньше опыта построения более сложных систем авторизации, обычно стараюсь брать для этой сферы готовое решение. У кого-то может быть есть опыт, или идеи, или готовые решения на основании которых это стоит делать?
Спасибо большое!
Зачем в основной бд хранить данные пользователей? Эту инфу можно запросить во время авторизации.
f
Я смотрю на это, как на взаимодействие с "вход гуглом" к примеру
IB
Зачем в основной бд хранить данные пользователей? Эту инфу можно запросить во время авторизации.
Потому что эту информацию о пользователях иногда требуется демонстрировать другим пользователям
IB
И делать на неё foreign key, привязывая к пользователю заказы, например
LL
Господа, а позвольте вопрос чуть отвлеченный от непосредственно эликсира?
У нас сейчас происходит обсуждение в компании, как правильно устравивать управление пользователями и авторизацией. При этом один из руководителей очень сильно топит за идею прям отдельного контура для паролей и рефреш-токенов: мол, во-первых, минимально необходимый код, который проще отсматривать, чтобы ничего не пересекалось по зонам ответственности; во-вторых, что бы никто не имел отдельного доступа к ползовательским токенам и не мог от их имени ничего сделать.
Однако есть и вторая сторона проблемы: данные пользователей должны по идее храниться в основной БД (что как бы норм вроде бы, сервис авторизации + resource server), что бы к ним ассоциировать всякое.
Посмотрели в сторону KeyCloak в качестве готового решения — поняли, что региистрацию нужно делать "через прокси", т.е. что бы собирать больше пользовательских дданых при регистрации, а так же что бы создавать соответствующую запись в основной БД. KeyCloak требует админского доступа от приложения, что бы регистировать пользователей не через свои формы, что несколько рушит концепт изоляции.
У меня не было раньше опыта построения более сложных систем авторизации, обычно стараюсь брать для этой сферы готовое решение. У кого-то может быть есть опыт, или идеи, или готовые решения на основании которых это стоит делать?
Спасибо большое!
У нас сейчас происходит обсуждение в компании, как правильно устравивать управление пользователями и авторизацией. При этом один из руководителей очень сильно топит за идею прям отдельного контура для паролей и рефреш-токенов: мол, во-первых, минимально необходимый код, который проще отсматривать, чтобы ничего не пересекалось по зонам ответственности; во-вторых, что бы никто не имел отдельного доступа к ползовательским токенам и не мог от их имени ничего сделать.
Однако есть и вторая сторона проблемы: данные пользователей должны по идее храниться в основной БД (что как бы норм вроде бы, сервис авторизации + resource server), что бы к ним ассоциировать всякое.
Посмотрели в сторону KeyCloak в качестве готового решения — поняли, что региистрацию нужно делать "через прокси", т.е. что бы собирать больше пользовательских дданых при регистрации, а так же что бы создавать соответствующую запись в основной БД. KeyCloak требует админского доступа от приложения, что бы регистировать пользователей не через свои формы, что несколько рушит концепт изоляции.
У меня не было раньше опыта построения более сложных систем авторизации, обычно стараюсь брать для этой сферы готовое решение. У кого-то может быть есть опыт, или идеи, или готовые решения на основании которых это стоит делать?
Спасибо большое!
Так а какие требования? 2fa? Социальные сети?
Или руководство хочет всё и сразу, только непоятно зачем?
Или руководство хочет всё и сразу, только непоятно зачем?
IB
Так а какие требования? 2fa? Социальные сети?
Или руководство хочет всё и сразу, только непоятно зачем?
Или руководство хочет всё и сразу, только непоятно зачем?
"в перспективе", как обычно
f
Потому что эту информацию о пользователях иногда требуется демонстрировать другим пользователям
Ну так запросите по апи. Вам вернется только то, что безопасно. И показывайте кому нужно.
IB
главное требование начальства - изолированность (хотя я не очень уверен, что это имеет большой смысл)
главное желание моё - что бы персданные хранились в общей БД, потому что их регулярно (и массово) нужно показывать, и завязывать на них другие таблицы, а делать слишком ненормализованную форму я очень не хочу
главное желание моё - что бы персданные хранились в общей БД, потому что их регулярно (и массово) нужно показывать, и завязывать на них другие таблицы, а делать слишком ненормализованную форму я очень не хочу
LL
"в перспективе", как обычно
Ну тогда и выбирайте любое решение. Если нет требований, то всем поебать
IB
Так я просто пока не могу найти минимально подходящее)
AB
Мне кажется, стоит начать с вопроса, а что же вы делаете
ŹR
минимально подходящее - хранить хеши паролей в бд и сессии в куке
LL
главное требование начальства - изолированность (хотя я не очень уверен, что это имеет большой смысл)
главное желание моё - что бы персданные хранились в общей БД, потому что их регулярно (и массово) нужно показывать, и завязывать на них другие таблицы, а делать слишком ненормализованную форму я очень не хочу
главное желание моё - что бы персданные хранились в общей БД, потому что их регулярно (и массово) нужно показывать, и завязывать на них другие таблицы, а делать слишком ненормализованную форму я очень не хочу
Ну если у вас архитектура полностью завязана на базе, то придётся интегрировать в монолит. Изолированность - лишняя боль
Если можете в сервисную архитектуру - то пожалуйста, хоть ссвой велосипед
Если можете в сервисную архитектуру - то пожалуйста, хоть ссвой велосипед
ŹR
Ну если у вас архитектура полностью завязана на базе, то придётся интегрировать в монолит. Изолированность - лишняя боль
Если можете в сервисную архитектуру - то пожалуйста, хоть ссвой велосипед
Если можете в сервисную архитектуру - то пожалуйста, хоть ссвой велосипед
ты так говоришь как будто монолит это плохо
LL
Требований нет - нет и советов
/thread
/thread
LL
ты так говоришь как будто монолит это плохо
Тебе показалось, я такого не имел в виду