1

I keep reading that IHttpContextAccessor should not be used with Blazor applications at all. However, the suggested approaches all seem to focus only on usage within a component. I am trying to access the http context during policy authorization, and I don't see a clear way to do this without injecting IHttpContextAccessor. Is it problematic during authorization as well?

MS specifically says:

Additionally, again for security reasons, you must not use IHttpContextAccessor within Blazor apps. Blazor apps run outside of the context of the ASP.NET Core pipeline. The HttpContext isn't guaranteed to be available within the IHttpContextAccessor, nor is it guaranteed to be holding the context that started the Blazor app.

Edit: This is not a duplicate question as I am talking about a specific location and a different era of Blazor (Microsoft's statement basically forbidding its use entirely didn't exist at the time of the question mine supposedly duplicates). Both the question and answers there do not address my specific use case (during authorization). I am asking about a specific place in which the _Host.cshtml is irrelevant as the authorization handler code is executed before _Host according to the order my breakpoints are being hit.

user15716642
  • 171
  • 1
  • 12
  • Where do you want to inject the IHttpContextAccessor, into your components ? You can't. What do you need the HttpContext for ? Note that you can add the HttpContext Accessor (AddHttpContextAccessor) in Startup.ConfigureServices, and use it there, as for instance, from a service you add to the DI container. – enet Nov 19 '22 at 12:35
  • @enet Are you suggesting that Microsoft needs to update that warning to specifically show that IHttpContextAccessor shouldn't be injected into components, but in other DI-injected services such as the authorization layer, this is acceptable? I described the IAuthorizationHandler as my targeted location btw. – user15716642 Nov 20 '22 at 14:24
  • It's really annoying that someone was so quick to close my question as a duplicate without reading much of it at all. I know very well how to inject IHttpContextAccessor. The premise is that the authoritative figure says that I should never do that in a Blazor app. AuthenticationState also has issues which are currently documented in an open github issue, and it does not contain information about the request or headers themselves. Now I have to wait for it to be reopened in order to offer a bounty or something and get a real answer. – user15716642 Nov 21 '22 at 19:31
  • @HenkHolterman As I mentioned, _Host breakpoints are not being hit until the breakpoints for authorization handlers have been. That's why. If this is only because I've messed something up in terms of middleware ordering, please let me know. – user15716642 Nov 21 '22 at 21:09
  • Your question is vague and general. It is better to describe your desired goal and share your authorization code in the form of a repository so that a better opinion can be given. – Arani Dec 05 '22 at 05:14
  • This applies to literally any usage of the IAuthorizationHandler interface, so I don't think it is vague at all. It is wide open enough to target any scenario in which you are trying to avoid using IHttpContextAccessor in any such an implementation of that interface. – user15716642 Dec 06 '22 at 06:08

1 Answers1

-1

If you have to use the HttpContext then you have to get the desired value(s) from HttpContext when rendering _Host.cshtml and save it in a variable and use that variable in the form of Cascading Parameters in the components in the rest of the program.

For example, I use the following procedure to get HttpContext in Blazor Server web application.

I modify the _Host.cshtml file as follows firstly. Here I'm looking for access_token information.

@{
    var token = await HttpContext.GetTokenAsync("access_token");
}

As you can see, I put the access_token information into the token variable and assign it to the component's param-AccessToken. Then I go to the App.razor file and define the AccessToken variable as a Cascading Value. As follows:

<CascadingValue Name="AccessToken" Value="AccessToken">
<CascadingAuthenticationState>
    <Router AppAssembly="@typeof(Program).Assembly">
        <Found Context="routeData">
            <AuthorizeRouteView RouteData="@routeData" DefaultLayout="@typeof(MainLayout)" />
        </Found>
        <NotFound>
            <LayoutView Layout="@typeof(MainLayout)">
                <p>Sorry, there's nothing at this address.</p>
            </LayoutView>
        </NotFound>
    </Router>
</CascadingAuthenticationState>
@code{
    [Parameter]
     public string AccessToken { get; set; }
 }

Finally, any components that need an AccessToken value just need to define it as a Cascade Parameter. For example, I create a component called ShowToken.razor and put its codes as below:

@page "/showtoken"

<p>This is part of the access token @(AccessToken != null ? AccessToken.Substring(0,30) : "(null)")</p>


@code {
    [CascadingParameter(Name = "AccessToken")] public string AccessToken { get; set; }
}

Because you receive HttpContext in the _Host.cshtml, so it will not threaten your program in terms of security.

Arani
  • 891
  • 7
  • 18
  • This is all described in the clickpath of the link I've provided. It does not apply to the authorization handler. My authorization is dependent upon specific additional header information in the request which is different from using it in some child components. – user15716642 Nov 20 '22 at 14:18
  • In the link you posted, it only gives a general explanation of how to use this method, while I have provided you with the code that is fully tested and is currently being used by myself in several projects. You should specify exactly in your question what you are looking for and what you expect from your program. – Arani Dec 05 '22 at 05:14
  • I don't agree here, honestly. I feel that the title alone is sufficient enough to indicate that your example is not relevant here as I mentioned a common interface MS provided and that you should be aware of before saying that it works in your answer. – user15716642 Dec 06 '22 at 06:06
  • You have mentioned in the question that it is not possible to use HttpContext in Blazor server at all. However, Microsoft has explicitly stated that it is possible to access HttpContext in one place, and it has been explained in detail and with examples in my answer. As is clear, your desired goal is to access HttpContext in Blazor server. – Arani Dec 06 '22 at 06:20
  • No I haven't, and at this point you are refusing to read what I said. I will end it here after reiterating: I said that Microsoft has explicitly told us to NOT use IHttpContextAccessor in blazor apps. I am in a scenario (using IAuthorizationHandler) in which none of the recommended methods seem to apply and simply need to know which route to go with in this case. – user15716642 Dec 06 '22 at 23:11