How should I access my ApplicationUser properties from ASP.NET Core Views?

Question

I\'m working on an ASP.Net vNext / MVC6 project. I\'m getting to grips with ASP.Net Identity.

The ApplicationUser class is apparently where I\'m suppose

Answer 1

You need to do a search (using e.g. Entity Framework) with the name of the current user:

HttpContext.Current.User.Identity.Name

Answer 2

Update to original answer: (This violates the op's first requirement, see my original answer if you have the same requirement) You can do it without modifying the claims and adding the extension file (in my original solution) by referencing FullName in the Razor View as:

@UserManager.GetUserAsync(User).Result.FullName

Original Answer:

This is pretty much just a shorter example of this stackoverflow question and following this tutorial.

Assuming you already have the property set up in the "ApplicationUser.cs" as well as the applicable ViewModels and Views for registration.

Example using "FullName" as extra property:

Modify the "AccountController.cs" Register Method to:

    public async Task<IActionResult> Register(RegisterViewModel model, string returnUrl = null)
        {
            ViewData["ReturnUrl"] = returnUrl;
            if (ModelState.IsValid)
            {
                var user = new ApplicationUser {
                    UserName = model.Email,
                    Email = model.Email,
                    FullName = model.FullName //<-ADDED PROPERTY HERE!!!
                };
                var result = await _userManager.CreateAsync(user, model.Password);
                if (result.Succeeded)
                {
                    //ADD CLAIM HERE!!!!
                    await _userManager.AddClaimAsync(user, new Claim("FullName", user.FullName)); 

                    await _signInManager.SignInAsync(user, isPersistent: false);
                    _logger.LogInformation(3, "User created a new account with password.");
                    return RedirectToLocal(returnUrl);
                }
                AddErrors(result);
            }

            return View(model);
        }

And then I added a new file "Extensions/ClaimsPrincipalExtension.cs"

using System.Linq;
using System.Security.Claims;
namespace MyProject.Extensions
    {
        public static class ClaimsPrincipalExtension
        {
            public static string GetFullName(this ClaimsPrincipal principal)
            {
                var fullName = principal.Claims.FirstOrDefault(c => c.Type == "FullName");
                return fullName?.Value;
            }   
        }
    }

and then in you views where you need to access the property add:

@using MyProject.Extensions

and call it when needed by:

@User.GetFullName()

The one problem with this is that I had to delete my current test user and then re-register in order see the "FullName" even though the database had the FullName property in it.

Answer 3

I have the same problem and the same concerns, however I have chosen a different solution instead creating an extension method to ClaimsPrincipal and let the extension method retrieve the custom user property.

Here is my extension method :

public static class PrincipalExtensions
{
    public static string ProfilePictureUrl(this ClaimsPrincipal user, UserManager<ApplicationUser> userManager)
    {
        if (user.Identity.IsAuthenticated)
        {
            var appUser = userManager.FindByIdAsync(user.GetUserId()).Result;

            return appUser.ProfilePictureUrl;
        }

        return "";
    }
}

Next in my view (also the LoginPartial view), I inject the UserManager and then transfer that UserManager to the extension method :

@inject Microsoft.AspNet.Identity.UserManager<ApplicationUser> userManager;
<img src="@User.ProfilePictureUrl(userManager)">

This solution I believe also meets your 3 requirements of separation of concerns, DRY and no change to any ViewModel. However while this solution is simple and can be used in standard views not only ViewComponents, I am still not happy. Now in my view I can write : @User.ProfilePictureUrl(userManager), but I think it would not be too much to ask that I should be able to write only : @User.ProfilePictureUrl().

If only I could make the UserManager (or IServiceProvider) available in my extension method without function inject it, it would solve the problem, but I know of no way to do that.

Answer 4

OK, here's how I eventually did it. I used a new feature in MVC6 called View Components. These work a bit like partial views, but they have a "mini controller" associated with them. The View Component is a lightweight controller that doesn't participate in model binding, but it can have something passed to it in constructor parameters, possibly using dependency injection and then it can construct a View Model and pass that to a partial view. So, for example, you can inject a UserManager instance into the View Component, use that to retrieve the ApplicationUser object for the current user and pass that to the partial view.

Here's what it looks like in code. First, the View Component, which lives in /ViewComponents directory:

public class UserProfileViewComponent : ViewComponent
    {
    readonly UserManager<ApplicationUser> userManager;

    public UserProfileViewComponent(UserManager<ApplicationUser> userManager)
        {
        Contract.Requires(userManager != null);
        this.userManager = userManager;
        }

    public IViewComponentResult Invoke([CanBeNull] ClaimsPrincipal user)
        {
        return InvokeAsync(user).WaitForResult();
        }

    public async Task<IViewComponentResult> InvokeAsync([CanBeNull] ClaimsPrincipal user)
        {
        if (user == null || !user.IsSignedIn())
            return View(anonymousUser);
        var userId = user.GetUserId();
        if (string.IsNullOrWhiteSpace(userId))
            return View(anonymousUser);
        try
            {
            var appUser = await userManager.FindByIdAsync(userId);
            return View(appUser ?? anonymousUser);
            }
        catch (Exception) {
        return View(anonymousUser);
        }
        }

    static readonly ApplicationUser anonymousUser = new ApplicationUser
        {
        Email = string.Empty,
        Id = "anonymous",
        PhoneNumber = "n/a"
        };
    }

Note that the userManager constructor parameter is injected by the MVC framework; this is configured by default in Startup.cs in a new project so there's no configuration to be done.

The view component is invoked, unsurprisingly, by calling the Invoke method or the asynchronous version of it. The method retrieves an ApplicationUser if possible, otherwise it uses an anonymous user with some safe defaultspreconfigured. It uses this user to its partiel view s the view model. The view lives in /Views/Shared/Components/UserProfile/Default.cshtml and starts like this:

@model ApplicationUser

<div class="dropdown profile-element">
    <span>
        @Html.GravatarImage(Model.Email, size:80)
    </span>
    <a data-toggle="dropdown" class="dropdown-toggle" href="#">
        <span class="clear">
            <span class="block m-t-xs">
                <strong class="font-bold">@Model.UserName</strong>
            </span> <span class="text-muted text-xs block">@Model.PhoneNumber <b class="caret"></b></span>
        </span>
    </a>

</div>

And finally, I invoke this from within my _Navigation.cshtml partial view like so:

@await Component.InvokeAsync("UserProfile", User)

This meets all of my original requirements, because:

1. I'm performing the database lookup in a controller (a View Component is a type of controller) and not in a View. Further, the data may well already be in memory as the framework will have already authenticated the request. I haven't looked into whether another database round trip actually happens, and I probably won't bother but if anyone knows, please chime in!
2. The logic is in one well-defined place; the DRY principle is respected.
3. I don't have to modify any other View Model.

Result! I hope someone will find this useful...

Answer 5

I think you should to use Claims property of User for that purpose. I found good post about: http://benfoster.io/blog/customising-claims-transformation-in-aspnet-core-identity

User class

public class ApplicationUser : IdentityUser
{
    public string MyProperty { get; set; }
}

Let's put MyProperty into Claims of Authenticated User. For this purpose we are overriding UserClaimsPrincipalFactory

public class MyUserClaimsPrincipalFactory : UserClaimsPrincipalFactory<ApplicationUser, IdentityRole>
{
    public MyUserClaimsPrincipalFactory (
        UserManager<ApplicationUser> userManager,
        RoleManager<IdentityRole> roleManager,
        IOptions<IdentityOptions> optionsAccessor) : base(userManager, roleManager, optionsAccessor)
    {
    }

    public async override Task<ClaimsPrincipal> CreateAsync(ApplicationUser user)
    {
        var principal = await base.CreateAsync(user);

        //Putting our Property to Claims
        //I'm using ClaimType.Email, but you may use any other or your own
        ((ClaimsIdentity)principal.Identity).AddClaims(new[] {
        new Claim(ClaimTypes.Email, user.MyProperty)
    });

        return principal;
    }
}

Registering our UserClaimsPrincipalFactory in Startup.cs

public void ConfigureServices(IServiceCollection services)
{
    //...
    services.AddScoped<IUserClaimsPrincipalFactory<ApplicationUser>, MyUserClaimsPrincipalFactory>();
    //...
}

Now we may access our propery like this

User.Claims.FirstOrDefault(v => v.Type == ClaimTypes.Email).Value;

We may create an extension

namespace MyProject.MyExtensions
{
    public static class MyUserPrincipalExtension
    {
        public static string MyProperty(this ClaimsPrincipal user)
        {
            if (user.Identity.IsAuthenticated)
            {
                return user.Claims.FirstOrDefault(v => v.Type == ClaimTypes.Email).Value;
            }

            return "";
        }
    }
}

We should add @Using to View (I add it to global _ViewImport.cshtml)

@using MyProject.MyExtensions

And finally we may use this property in any View as method calling

@User.MyProperty()

---

In this case you haven't additional queries to database for getting user information.

Answer 6

As I have been asked about it, I'm posting my eventual solution, albeit in a different (MVC5/EF6) project.

First, I defined an interface:

public interface ICurrentUser
    {
    /// <summary>
    ///     Gets the display name of the user.
    /// </summary>
    /// <value>The display name.</value>
    string DisplayName { get; }

    /// <summary>
    ///     Gets the login name of the user. This is typically what the user would enter in the login screen, but may be
    ///     something different.
    /// </summary>
    /// <value>The name of the login.</value>
    string LoginName { get; }

    /// <summary>
    ///     Gets the unique identifier of the user. Typically this is used as the Row ID in whatever store is used to persist
    ///     the user's details.
    /// </summary>
    /// <value>The unique identifier.</value>
    string UniqueId { get; }

    /// <summary>
    ///     Gets a value indicating whether the user has been authenticated.
    /// </summary>
    /// <value><c>true</c> if this instance is authenticated; otherwise, <c>false</c>.</value>
    bool IsAuthenticated { get; }

Then, I implement that in a concrete class:

/// <summary>
///     Encapsulates the concept of a 'current user' based on ASP.Net Identity.
/// </summary>
/// <seealso cref="MS.Gamification.DataAccess.ICurrentUser" />
public class AspNetIdentityCurrentUser : ICurrentUser
    {
    private readonly IIdentity identity;
    private readonly UserManager<ApplicationUser, string> manager;
    private ApplicationUser user;

    /// <summary>
    ///     Initializes a new instance of the <see cref="AspNetIdentityCurrentUser" /> class.
    /// </summary>
    /// <param name="manager">The ASP.Net Identity User Manager.</param>
    /// <param name="identity">The identity as reported by the HTTP Context.</param>
    public AspNetIdentityCurrentUser(ApplicationUserManager manager, IIdentity identity)
        {
        this.manager = manager;
        this.identity = identity;
        }

    /// <summary>
    ///     Gets the display name of the user. This implementation returns the login name.
    /// </summary>
    /// <value>The display name.</value>
    public string DisplayName => identity.Name;

    /// <summary>
    ///     Gets the login name of the user.
    ///     something different.
    /// </summary>
    /// <value>The name of the login.</value>
    public string LoginName => identity.Name;

    /// <summary>
    ///     Gets the unique identifier of the user, which can be used to look the user up in a database.
    ///     the user's details.
    /// </summary>
    /// <value>The unique identifier.</value>
    public string UniqueId
        {
        get
            {
            if (user == null)
                user = GetApplicationUser();
            return user.Id;
            }
        }

    /// <summary>
    ///     Gets a value indicating whether the user has been authenticated.
    /// </summary>
    /// <value><c>true</c> if the user is authenticated; otherwise, <c>false</c>.</value>
    public bool IsAuthenticated => identity.IsAuthenticated;

    private ApplicationUser GetApplicationUser()
        {
        return manager.FindByName(LoginName);
        }
    }

Finally, I make the following configuration in my DI kernel (I'm using Ninject):

        kernel.Bind<ApplicationUserManager>().ToSelf()
            .InRequestScope();
        kernel.Bind<ApplicationSignInManager>().ToSelf().InRequestScope();
        kernel.Bind<IAuthenticationManager>()
            .ToMethod(m => HttpContext.Current.GetOwinContext().Authentication)
            .InRequestScope();
        kernel.Bind<IIdentity>().ToMethod(p => HttpContext.Current.User.Identity).InRequestScope();
        kernel.Bind<ICurrentUser>().To<AspNetIdentityCurrentUser>();

Then whenever I want to access the current user, I simply inject it into my controller by adding a constructor parameter of type ICurrentUser.

I like this solution as it nicely encapsulates the concern and avoids my controllers having a direct dependency on EF.