Regarding Blazor and IHttpContextAccessor

[NiTi80]

According to the page below you should avoid using IHttpContextAccessor in Blazor Server Apps.
https://docs.microsoft.com/en-us/aspnet/core/blazor/security/server/threat-mitigation?view=aspnetcore-3.1

My question regarding this is: Is there a risk that you might get access to the HttpContext from another user's session or is the risk only that you could get Null or a HttpContext that is related to you but is from another request?

I found the example that shows how to retrieve information from the HttpContext in the page and propagate it further.
https://github.com/javiercn/blazor-server-aad-sample

I saw this issue that seems to be resolved and which seems to take care of the risk of getting the wrong HttpContext, but I don't really know how it relates to Blazor Server
#14975

Does anyone know what the real caveats and risks are when using IHttpContextAccessor in Blazor Server?

[SteveSandersonMS]

Does anyone know what the real caveats and risks are when using IHttpContextAccessor in Blazor Server?

I think you can't count on IHttpContextAccessor returning anything. Our recommended deployment environment for Blazor Server is using the Azure SignalR service (see: Deploying Blazor Server), and in this case, there won't be any HttpContext associated with the connections.

@javiercn Do you have anything to add to this?

[javiercn]

@NiTi80 the issue being resolved doesn't mean the risk has been avoided. The recommendation https://docs.microsoft.com/en-us/aspnet/core/blazor/security/server/threat-mitigation?view=aspnetcore-3.1#blazor-and-shared-state still applies

[NiTi80]

@javiercn Does the risk include getting access to a HttpContext that might belong to another user's session?

Edit: We have started implementing the recommended way of accessing HttpContext as shown in your example

[javiercn]

Yep, the guidance is there for that reason.

[NiTi80]

@javiercn Yes, it is good to know though that the risk exists. Thank you for answering my question.