Información del usuario en Nancy

Question

Estoy juntando una aplicación de demostración basada en Nancy.Demo.Authentication.Forms.

estoy poniendo en práctica ClaimsUserName y en mi clase UserIdentity:IUserIdentity y, de acuerdo con la demo, Tengo un UserModel con UserName.

En la clase SecureModule, puedo ver que el Context.CurrentUser se puede usar para ver quién ha iniciado sesión, pero según la interfaz, esto solo proporciona el nombre de usuario y los reclamos. Si luego necesito obtener más datos (por ejemplo, mensajes para el usuario conectado) para un modelo de vista, todo lo que puedo ver para usar como filtro para una consulta de db es el nombre de usuario, que se siente, bueno, raro. Prefiero usar el uniqueIdentifier del usuario.

Creo que lo que estoy tratando de llegar al fondo de, si es mejor agregar los campos adicionales a mi IUserIdentity implementación, o al UserModel? ¿Y dónde poblar estos?

No estoy seguro de que mi pregunta sea tan clara (¡No está claro en mi cabeza!), Pero algunos consejos generales de arquitectura básica serían un placer.

Answer 1

Lo siento por la respuesta tardía .. poco agitado en el momento :)

El IUserIdentity es la interfaz mínima requerida para utilizar construido en ayudantes de autenticación, puede implementar eso y añadir información adicional tanto de Nancy como desee a tu clase; es similar al .net estándar IPrincipal. Si agrega su propia información, obviamente tendrá que utilizar su tipo de implementación para acceder a los campos adicionales. Podríamos agregar un método CurrentUser para evitar que tenga que hacer eso, pero parece un poco redundante.

Usted puede dejar de leer aquí, si se quiere, o se puede leer en si está interesado en cómo las formas de autenticación funciona ..

FormsAuth utiliza una implementación de IUsernameMapper (que probablemente se denomina mal ahora) para convertir entre el identificador de usuario Guid que está almacenado en la cookie del cliente y el usuario real (IUserIdentity). Vale la pena señalar que este GUID debe asignarse al usuario/id en algún lugar, pero no es su clave principal de base de datos, es simplemente una capa de indirección entre sus id (nombres de usuario) (probablemente predecibles) y el "token" almacenado en el cliente Aunque las cookies están encriptadas y HMACd (dependiendo de su configuración), si alguien logra abrir y reconstruir la cookie de autenticación, tendría que adivinar el GUID de otra persona para suplantarlas, en lugar de cambiar un nombre de usuario (a "admin" o algo similar), o una identificación (a 1 para el primer usuario).

esperanza que tiene sentido :)