Home/ Questions/Q 7410641
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-29T06:15:53+00:00

I’m knocking together a demo app based upon Nancy.Demo.Authentication.Forms . I’m implementing Claims and

  • 0

I’m knocking together a demo app based upon Nancy.Demo.Authentication.Forms.

I’m implementing Claims and UserName in my UserIdentity:IUserIdentity class and, as per the demo, I’ve got a UserModel with UserName.

In the SecureModule class, I can see that the Context.CurrentUser can be used to see who it is that’s logged on, but as per the interface, this only supplies the username and the claims. If I then need to get more data (say messages for the logged on user) for a view model, all I can see to use as a filter for a db query is the username, which feels, well, weird. I’d much rather be using the uniqueIdentifier of the user.

I think what I’m trying to get to the bottom of, if it is better to add the extra fields to my IUserIdentity implementation, or to the UserModel? And where to populate these?

Not sure my question is that clear (It’s not clear in my head!), but some general basic architecture advice would go down a treat.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Sorry for the delayed reply.. bit hectic at the moment 🙂

    The IUserIdentity is the minimum interface required to use Nancy’s built in authentication helpers, you can implement that and add as much additional information as you like to your class; it’s similar to the standard .net IPrincipal. If you do add your own info you’ll obviously have to cast to your implementation type to access the additional fields. We could add a CurrentUser method to stop you having to do that, but it seems a little redundant.

    You can stop reading here if you like, or you can read on if you’re interested in how forms auth works..

    FormsAuth uses an implementation of IUsernameMapper (which is probably named wrong now) to convert between the Guid user identifier that’s stored in the client cookie and the actual user (the IUserIdentity). It’s worth noting that this GUID needs to be mapped to the user/id somewhere, but it’s not intended to be your database primary key, it is merely a layer of indirection between your (probably predictable) user id/names and the “token” stored on the client. Although the cookies are encrypted and HMACd (depending on your configuration), if someone does manage to crack open and reconstruct the auth cookie they would have to guess someone else’s GUID in order to impersonate them, rather than changing a username (to “admin” or something smilar), or an id (to 1 for the first user).

    Hope that makes sense 🙂

    • 0