Как решить проблемы первого пользователя учитывая архитектуру проекта?
Здравствуйте!
Столкнулся с проблемой создания первого пользователя. Проект подходит уже к финальной стадии и теперь пришло время изменить UserEntity.Password на User.HashedPassword. Процесс создания (регистрации) уже решился, но теперь не могу никак определиться, как мне сделать первого пользователя
До этого я использовал обычный .HasData(...), но теперь пароль нужно прогнать через соответствующий сервис хеширования. Этот сервис подключается через DI в другие сервисы в соответствующей прослойке логики.
Тут и появляется проблема внедрение этого сервиса и обеспечения БД наличием первого пользователя. Сервис для хеширования не должен быть внедрён в библиотеку с DbContext и GenericRepository, а должен использоваться на уровне сервисов. Сервисы имеют доступ к GenericRepository (Имеет public DbSet).
У первого юзера вообще может быть пустое поле хэша, не совпадающее ни с каким паролем - главное, прописать ему его почту, с которой он может запросить смену пароля и прописать, какой ему хочется.
Так создайте сейчас первого пользователя с нужным паролем и в .HasData(...) пропишите полученный хеш.
И при первом использовании просто предложите данному пользователю сменить пароль. Такой ведь механизм у вас есть
Это немного не подходит, т.к. может меняться сам алгоритм. Для каждой системы должен/может создаваться юзер с резным хеш-паролем/паролем. Нужно интегрированное решение, не требуемое ручного вмешательства
Nik Faraday, а если будет меняться сам алгоритм, то старые хэши паролей будут уже не валидны - значит алгоритм менять нельзя и решение работает.
Я сам так делал не раз.
Nik Faraday, Такое решение используется во всех системах. Всегда есть админ с паролем по умолчанию.
Можете конечно инсталер сделать и там задавать пароль при установке
