0

My users log in using an email address and their password using my custom membership provider. Is there a way to have User.Identity.Name (or something else within there) return the users real name and not their username (or email address in my case) while keeping the email address so that can still be used? If that isn't a good way to do what I want, what do you recommend to do instead?

I think "Welcome Mike Wills" looks better than "Welcome bigdaddy124@mydomain.com".

Mike Wills
  • 20,959
  • 28
  • 93
  • 149

3 Answers3

2

You can add the user's profile object (or name) to a Session variable, so you won't have to query the database for each pageload.

Balazs Tihanyi
  • 6,659
  • 5
  • 23
  • 24
  • There are far better architectural alternatives than using the session object (if you aren't already) Theres zero strongly type anything here. you are stuck using magic strings, and you must be aware that forms auth timeouts and session timeouts don't sync up. – Adam Tuliper Mar 19 '12 at 16:33
  • @AdamTuliper I think a helper class that handles the cached variable's lifetime would do this whole job properly. I don't see anything wrong with that design. – Balazs Tihanyi Mar 19 '12 at 16:55
  • It's not strongly typed. If you have a helper class that reads the session, why not just store it in current user's info in IPrinciple as opposed to magic strings, session timeout vs. forms auth timeout issues (most aren't aware of this issue but it can surely bite you even if timeouts are set the exact same), etc etc – Adam Tuliper Mar 20 '12 at 03:36
  • @AdamTuliper-MSFT Having an implementation of `IPrincipal` that throws a `NotImplementedException` for `IsInRole(string role)` (because I don't want to use that, did someone say "magic strings"?), is not an ideal situation either. – user247702 Feb 26 '13 at 14:21
  • 1
    @Stijn Take the lesser of two evils then. Session object locks and prevents serialized ajax requests (literally blocks any new requests that use the session object for that user until that first request is done which can kill performance) and the aforementioned reasons as well (forms auth and session timeouts need special workarounds to sync them - most aren't aware of that issue either) strongly typed issues, etc. – Adam Tuliper Feb 27 '13 at 07:03
1

The best way here is to implement a custom principle so the fields are available, don't try to 'misuse' existing fields. Simply cast the IPrinciple usage to your principle class and reference the FullName field (or whatever you call it)

Implementing IPrincipal and IIdentity in MVC with use of custom membership and role provider

Community
  • 1
  • 1
Adam Tuliper
  • 29,982
  • 4
  • 53
  • 71
0

A separate "Users" DB table to store personal info that is related to the Membership table....

That way it keeps your authentication and authorization data separated from (but linked to) your custom user data. Makes it easier to manage IMHO.

Greg
  • 31,180
  • 18
  • 65
  • 85