Информация о пользователе в Нанси

Question

Я собираю демонстрационное приложение на основе Nancy.Demo.Authentication.Forms .

Я реализую Claims и UserName в своем классе UserIdentity:IUserIdentity и, согласно демонстрации, у меня есть UserModel с UserName.

В классе SecureModule я вижу, что Context.CurrentUser может использоваться, чтобы увидеть, кто это вошел в систему, но в соответствии с интерфейсом, он предоставляет только имя пользователя и утверждения. Если затем мне понадобится получить больше данных (скажем, сообщений для вошедшего в систему пользователя) для модели представления, все, что я смогу использовать в качестве фильтра для запроса базы данных, - это имя пользователя, что выглядит странно. Я бы предпочел использовать uniqueIdentifier пользователя.

Я думаю, к чему я стремлюсь, если лучше добавить дополнительные поля в мою реализацию IUserIdentity или в UserModel? И где их заселить?

Не уверен, что мой вопрос так ясен (это не ясно в моей голове!), Но некоторые общие базовые рекомендации по архитектуре могли бы сойти с ума.

Answer 1

Извините за задержку с ответом .. немного беспокойный в данный момент:)

IUserIdentity - это минимальный интерфейс, необходимый для использования встроенных помощников по аутентификации Нэнси, вы можете реализовать это и добавить столько дополнительной информации, сколько вам нравится в вашем классе; это похоже на стандартный .net IPrincipal . Если вы добавите свою собственную информацию, вам, очевидно, придется привести ее к типу реализации, чтобы получить доступ к дополнительным полям. Мы могли бы добавить метод CurrentUser, чтобы вам не пришлось это делать, но он кажется немного излишним.

Вы можете прекратить чтение здесь, если хотите, или можете читать дальше, если вам интересно, как работает аутентификация форм ..

FormsAuth использует реализацию IUsernameMapper (которая, вероятно, теперь называется неправильной) для преобразования между идентификатором пользователя Guid, который хранится в файле cookie клиента, и фактическим пользователем (IUserIdentity). Стоит отметить, что этот GUID должен быть где-то сопоставлен с user / id, но он не предназначен для того, чтобы быть первичным ключом вашей базы данных, это просто слой косвенности между вашими (вероятно, предсказуемыми) идентификаторами / именами пользователя и «токеном» хранится на клиенте. Несмотря на то, что файлы cookie зашифрованы и HMACd (в зависимости от вашей конфигурации), если кому-то удастся взломать и восстановить файл cookie авторизации, ему придется угадывать чужой GUID, чтобы имитировать их, а не менять имя пользователя (на «admin»). или что-то неладное), или идентификатор (до 1 для первого пользователя).

Надеюсь, это имеет смысл:)