[Feature request] Make it able to pass custom ClaimsPrincipal when using TestServer about testing

[rynowak]

aspnet/Mvc#6233

[davidfowl]

This should be moved to aspnet/Hosting.

@rynowak You were discussing being able to get a RequestDelegate instead of an HttpClient from the TestServer. Did you file an issue for that anywhere?

[ferrx]

the "best" way to currently test is to check for existence of attributes through reflection and unit-test the components separately @kasparkallas

Can you explain further or link to a guide? Do you just mean checking to see if the [Authorization] data attribute is attached to a method via reflection and perform some forked set of actions for authorized and not-authorized behavior?

I assume this would not take granular claims assessment into account, i.e. if your controller was checking to see if the current user HasClaims..

[kasparkallas]

@ferrx Yes, I did mean checking for the presence of the attribute via reflection. Which is clearly not a good way to test it because of all the possible combinations of attributes, filters and explicit authorization logic in controller (like you said). Sorry, I don't have an article to share.

I have been informed that the ClaimsPrincipal can be passed when using the open-source ASP.NET Core integration testing project Alba which does the same thing as TestHost but exposes RequestDelegate (if I understand correctly).

A code example setting up WindowsPrincipal for User that I got from Alba's Gitter room (thanks @joemcbride):

private Task<IScenarioResult> run(Action<Scenario> configuration)
{
    using (var system = SystemUnderTest.ForStartup<Startup>())
    {
        system.Environment.EnvironmentName = "Development";
        return system.Scenario(configuration);
    }
}

[Fact]
public async Task authenticated_values()
{
    var result = await run(_ =>
    {
        var identity = WindowsIdentity.GetCurrent();
        var principal = new WindowsPrincipal(identity);
        _.Context.User = principal;
        _.Get.Url("/api/values");
        _.Context.Request.Method.ShouldBe("GET");
    });

    result.Context.Response.StatusCode.ShouldBe(200);

    var output = result.ResponseBody.ReadAsJson<string[]>();
    output.ShouldNotBeNull();
    output.ShouldBe(new []{ "value1", "value2"});
}

[rynowak]

@javiercn - is it possible to use Microsoft.AspNetCore.Mvc.Testing to get a RequestDelegate?

[davidfowl]

The test server takes an IWebHostBuilder which creates an IApplicationBuilder and uses pretty much the entire hosting pipeline. There's no way to get the request delegate directly.

[javiercn]

I believe is trivial to expose the request delegate from TestServer.

That said, If i were to set the principal in the HttpContext at the beginning of the request, I would just do it with a startup filter in the same fashion that we do to setup the request culture.

Create a startup filter, plug it in DI and make it setup a middleware that sets the principal to whatever you are expecting.

If we were to expose the request delegate you would need to be responsible of creating the HttpContext yourself and I'm not sure of the subtleties that might have (it might be doable)

[javiercn]

https://github.com/aspnet/Mvc/blob/dev/src/Microsoft.AspNetCore.Mvc.Testing/Internal/CultureReplacerStartupFilter.cs

[davidfowl]

I believe is trivial to expose the request delegate from TestServer.

I'm not sure it is, but we should discuss offline.

[aspnet-hello]

This issue was moved to dotnet/aspnetcore#2357