Is it appropriate to use IHttpcontextAccessor in service layer?

I have multiple layers in may .net core web application. So the two of them are;

• App.WebApi
• App.Services

Services need to check role or name claims of user. So I think I can use IHttpcontextAccessor interface via dependency injection in App.Services layer. I am using extension methods to get user claims like following.

public static class ClaimsPrincipalExtensions
{
    public static string GetUserEmail(this ClaimsPrincipal principal)
    {
        return principal.FindFirstValue(ClaimTypes.Email);
    }

    public static string GetUserId(this ClaimsPrincipal principal)
    {
        return principal.FindFirstValue(ClaimTypes.NameIdentifier);
    }
}

And service layer implementation is like following

public class ProductService: IProductService {
    IHttpcontextAccessor context;

    public ProductService(IHttpcontextAccessor context){
       context = context;
    }
    ....
    ....
    public IEnumerable<Product> Get(){
        var userRoles = context.HttpContext.User.GetUserEmail();
        ....
    }
}

SO I am using IHttpcontextAccessor in service layer. But it is part of web api. Is this appropriate for professional solutions? Or is there any other way?

In my experience, in ASP.NET developers tend not to worry much about these segregation concerns (nor about e.g. anemic domains).

In most systems, especially smaller ones, there is a lot of coupling between the business logic and the API; for example through the use of filters and middleware.

So, in this sense it can be seen as 'appropriate', as long as it doesn't block you from an important project requirement, for example being able to run the application core independently of the API.

But if you want to architect your solution in a decent and modern way, it makes sense to avoid doing things like this.

Straightforward solution

One straightforward solution is to extract the given data into a separate 'service', with an interface defined in the layer that consumes the given service. And then implement the interface in the WebApi project.

A good example is Jason Taylor's Clean Architecture Template, where you have an ICurrentUserService interface defined in the Application layer, with the concrete implementation residing in the WebUI layer.

This also uses the IHttpContextAccessor to extract information about the logged in user, so it seems like a great example for what you want to do.

Helpful references

I know it's not customary to link YouTube videos here, but it seems your main area of expertise is not ASP.NET Core, so I'd suggest this Vertical Slice Architecture talk from Jimmy Bogard, and this Clean Architecture talk from Jason Taylor. They describe a quite modern way of working with ASP.NET Core that can mitigate a lot of structural problems developers experience with their projects later on. Of course this is not a silver bullet either; for simple CRUD apps the overhead might not worth it.

Let me know if you have additional concerns or questions, so I could make this answer more useful.