How to read user claims from Automapper Value Resolver

Sergio Barriel — Thu, 10 Jun 2021 21:33:44 +0000

Sometimes we need to send to our services objects that include existing data in the user’s claims.

To avoid fattening controllers, let’s see how to make Automapper do this work for us.

In our example, we will try to create a company and only receive the name and description, but obviously, we are interested in knowing which user has made this action.

The model that exposes the API is CreateCompany and the DTO that we send to the service is CreateCompanyDto. Both models are the same, except the last one, which incorporates a property that stores the user’s identifier.

Step 1: Install Nuget packages

To make this solution to work correctly, we will need these two packages:

Step 2: Register IHttpContextAccessor interface into DI container

Why? because IHttpContextAccessor is not registered by default for performance reasons. You can read on Github a thread with a discussion about it.

public void ConfigureServices(IServiceCollection services)
{
    services.AddTransient<IHttpContextAccessor, HttpContextAccessor>();

    services.AddAutoMapper(configuration =>
    {
        configuration.AddProfile<CompanyProfile>();
    });

    services.AddMvc();
}

Step 3: Create Automapper profile

On our Automapper profile, we will specify which "custom value solver" we will use to recover the desired value of the user's claims

public class CompanyProfile : Profile
{
    public CompanyProfile()
    {
        CreateMap<CreateCompany, CreateCompanyDto>()
            .ForMember(destination => destination.UserId, option => option.ResolveUsing<UserIdResolver>());
    }
}

Step 4: Create "Custom Value Resolver"

We must inject IHttpContextAccessor interface on class constructor so that afterwards, the "Resolve" method is able to read the property.

In this case, we read "NameIdentifier" claim as our user identifier, but we can read anything.

public class UserIdResolver : IValueResolver<object, object, string>
{
    private readonly IHttpContextAccessor _contextAccessor;

    public UserIdResolver(IHttpContextAccessor contextAccessor)
    {
        _contextAccessor = contextAccessor;
    }

    public string Resolve(object source, object destination, string destinationMember, ResolutionContext context)
    {            
        return _contextAccessor.HttpContext.User.Claims
            .Where(x => x.Type == ClaimTypes.NameIdentifier)
            .Select(c => c.Value).SingleOrDefault();
    }
}

Step 5: Create controller and mapping data

Now, we will be able to map both classes in a single line and this is because Automapper will be in charge of recovering the value that we need from the claims.

[HttpPost]
[Authorize]
public async Task<IActionResult> CreateCompanyAsync(CreateCompany request)
{
    var mapped = _automapper.Map<CreateCompanyDto>(request);

    return Ok(await _companyService.CreateCompanyAsync(mapped));
}

Notice: This post was published originally on Medium platform on april 17, 2018

How to automatically validate a model with MVC filter and Fluent Validation package

Sergio Barriel — Thu, 10 Jun 2021 20:16:59 +0000

I have had the opportunity to see many MVC projects and in the vast majority of them I find structures where the view models are manually validated in all the methods of all the controllers.

At best, the code relies on verifying ModelState property from Controller class, but in the worst case… better not to comment it.

[Route("")]
[HttpPost]
public async Task<IActionResult> CreatePostAsync([FromBody] CreatePost request)
{
    if (ModelState.IsValid)
    {
        return Ok(await _postService.CreateAsync(request));
    }
    return BadRequest(ModelState.ValidationState);
}

So, it exists a more elegant solution for this… let’s see it

In our example, we will validate a view model called CreatePost before the request reaches the controller PostController, and after that, we will send the request to properly service

Step 1: Install nuget packages

FluentValidation.AspNetCore by Jeremy Skinner

Step 2: Create validator

With FluentValidation package, all our validators are classes that inherits from AbstractValidator, where is our view model.

In this step, we’re making sure that the “Title” and “Content” properties from “CreatePost” view model are never empty, like [Required] data annotation.

public class CreatePostValidator : AbstractValidator<CreatePost>
{
    public CreatePostValidator()
    {
        RuleFor(x => x.Title).NotEmpty();
        RuleFor(x => x.Content).NotEmpty();
    }
}

As you can see, in class constructor, you can add rules for each property and combine as you need.

This is a more complete example with conditional rules for a more flexible scenario, where we can allow authentication with a username or email, but always one of the two.

public class LoginValidator : AbstractValidator<Login>
{
    public LoginValidator()
    {
        RuleFor(x => x.UserName)
            .NotEmpty()
            .When(x => !DataTypesHelper.IsEmail(x.Email) && string.IsNullOrEmpty(x.Email))
            .WithMessage("Username or email are required");

        RuleFor(x => x.Email)
            .NotEmpty()
            .When(x => string.IsNullOrEmpty(x.UserName))
            .WithMessage("Username or email are required");

        RuleFor(x => x.Password)
            .NotEmpty()
            .WithMessage("Password is required");
    }
}

If you need, you can read the complete documentation about FluentValidation from Github repository.

Step 3: Create MVC filter

As shown on this post about MVC lifecycle by Matthew Jones, Action Filters are invoked before and after controller, but we are interested in validating our model only before invoking the controller, so for this reason we will use OnActionExecuting method.

https://www.asp.net/media/4071077/aspnet-web-api-poster.pdf

At this point, we will check ModelState, which internally will apply the rules that we have defined with FluentValidation

public class ModelStateFilter : IActionFilter
{
    public void OnActionExecuting(ActionExecutingContext context)
    {
        if (!context.ModelState.IsValid)
        {
            context.Result = new BadRequestObjectResult(context.ModelState);
        }
    }
    public void OnActionExecuted(ActionExecutedContext context) { }
}

Code example is based on this Gist

Step 4: Register services into DI container

When adding the MVC service to the DI container, we must specify the action filters that we want to use, and then, specify in which assembly are the validators of our view models.

public void ConfigureServices(IServiceCollection services)
{
    services.AddMvc(options =>
        {
            options.Filters.Add(new ModelStateFilter());
        })
        .AddFluentValidation(options =>
        {
            options.RegisterValidatorsFromAssemblyContaining<Startup>();
        });
}

Step 5: Create controller method

The last step is to create a method in our controller, which meets the requirement of being lightweight.

[Route("")]
[HttpPost]
public async Task<IActionResult> CreatePostAsync([FromBody] CreatePost request)
{
    return Ok(await _postService.CreateAsync(request));
}

If you invoke the method with the wrong view model, you will receive a response like “400 Bad Request” with the errors summary.

POST /post HTTP/1.1
Host: localhost:50555
Content-Type: application/json
Cache-Control: no-cache
Postman-Token: c5f7b803-dfe2-a315-eb8f-671b84cb3175

{
    "Title": "",
    "Content": "",
    "Excerpt": ""
}

{
    "Title": [
        "'Title' should not be empty."
    ],
    "Content": [
        "'Content' should not be empty."
    ]
}

Notice: This post was published originally on Medium platform on may 2, 2018

DEV Community: Sergio Barriel

How to read user claims from Automapper Value Resolver

How to automatically validate a model with MVC filter and Fluent Validation package