Dangers of using IHttpContextAccessor

IHttpContextAccessor is a great way to access the HttpContext, until it's not. Learn how to avoid troubles with the IHttpContextAccessor and how it works under the hood.
Patreon 🤝 / raw_coding
Courses 📚 learning.raw-c...
Shop 🛒 shop.raw-codin...
Discord 💬 / discord
Twitter 📣 / anton_t0shik
Twitch 🎥 / raw_coding
#aspnetcore #csharp #dotnet

[@MrJonnis13]

We are waiting for that *AsyncLocal* dedicated video :) Thank you Anton.

[@mihaiga]

The first time I have encountered this problem was during EF Core migration. If you assume that the httpcontext exists and a service constructor uses the context then the constructor fails and the EF Core tools remain stuck without giving any errors. Troubleshooting this issue was a very valuable lesson.

[@aokijikuzan2131]

Wow just heard that you will visit one of our offices with a presentation, too bad I work in other office. Thank you for sharing knowledge

[@RawCoding]

I’ll see if it can be a live cal or something like that

[@sranmajstorovic2935]

AService issue can happen with any service registered as scoped if the work done inside AService is "background work" (not awaited) done by those scoped services. Request is finished before the work (because work is not awaited), and services registered as scoped are disposed in the middle of the work. Kaboom Solution is not to await but to have another scope for background work initiated from http request.

[@unskeptable]

When is the new scope disposed ? Does it get automatically disposed after the background job is finished ?

[@sranmajstorovic2935]

​@@unskeptable No, scope is disposed when http request is finished, and http request does not wait for "background job. So if you dont await a Task (whatever it is), and its execution last longer than execution of request (scope), if task dependencies are registered as scoped, task will fail, because dependencies are destroyed. Solution is to create new Scope manualy for background stuff, and that will create diferent instances of registered dependencies.

[@sagivalia5041]

So it's safe to use IHttpContextAccessor in a within a controller logic since the HTTP context is still active and be careful when using it with custom services which are not related to the HTTP context itself?

[@shoobidyboop8634]

One day I saw IHttpContextAccessor smoking by the bike rack, and I never used it since.

[@RaymondYokogawa]

The main takeaway for me is that the backend logic should NOT be dependent on the application framework (e.g. ASP or WCF etc). So I did not push through with the use of HttpContextAccessor to migrate a WCF backend service that depends on the WCF HTTPContext

[@BenScott2096]

That was excellent. Very clear!

[@nanvlad]

I didn't get the point why we missed HttpContext after await Task.Delay(). Since it's stored as AsyncLocal it should be there when continuation thread is perfoming further action. Or with thread continuation there will be a different context where HttpContext is not set?

[@RawCoding]

as the httpcontext is retained in the service, the execution continues we've seen in the DefaultHttpContext at Kestrel level that is where HttpContext is cleared from HttpContextAccessor delay finishes and HttpContext is no longer there null pointer exception

[@unskeptable]

I think he is talking about httpcontextaccessor. But not sure

[@StevenHartgers]

Take a shot each time "HTTP context accessor" is said, RIP 😂

[@RawCoding]

😂

[@ahjsbkdjhavkcjhvac]

you're the anthonywrites code of C#

[@nathanbrown2387]

Great video! So if I have a flow which follows this pattern: 1. Controller action is hit 2. Controller constructs and sends a command with MediatR 3. Inside the command handlers we have an ICurrentUserService which uses IHttpContextAccessor Then we could run into problems? (If so is there any way to avoid having to pass the user information into each command in the controller?)

[@nove1398]

This was going to be my question as well

[@RawCoding]

If ICurrentUserService is a scoped service you can preload it in the middleware after authentication middleware. Dependency Injection is really bad for this - if you let this image in your mind sink in - you can’t see all the object coming to fulfill your handler. So you end up with ICurrentUser interfaces which have to be prepared. In your case it’s not prepared but implemented with Ihttpcontext, if you want to reuse a service somewhere else you’ll have to supply different implementation; now you have 2 services behind same interface, which one do you inject? Well now you have to inject Ienumerable and pick by type and hopefully you can see how shit this is. Preparing is a bit cleaner when your using DI, ideally you want to do this without DI at handler level where you prepare everything, but MediatR is shit since it promises portability but really destroys the point of transition between server to BL.

[@nathanbrown2387]

@@RawCoding I see, so does preloading mean we can inject it into a custom middleware after Authentication, set the properties needed from the HTTPContext, and then have those values available to other services? (Essentially breaking the dependency on IHTTPContextAccessor)?

[@pedroferreira9234]

@@nathanbrown2387 and that service will be scoped or transite by default.

[@nathanbrown2387]

Actually further to this, (apologies if there is an obvious answer), doesn't preloading this service in middleware imply we have some sort of Setter on the User Service to set the current user properties? And if so doesn't that mean that all downstream services will also be able to overwrite it?

[@mohamadyousef163]

So the fix is to inject the accessor into mapgets lambdas ?

[@RawCoding]

You might have missed the point, you’re thinking surface level (how do I use a service) rather than deeper understanding (how does the service works) To answer your question directly: just use httpcontext in mapget no need for accessor

[@sauravbhatta5303]

Nice video Hopefully ur c# has advanced topics as well

[@kostasgkoutis8534]

Nice video, I've come across this issue, indeed

[@Petoj87]

Is there the httpcontextaccessors fault or your fault for not awaiting?...

[@RawCoding]

Don’t think it’s anyone’s fault, kinda like you have to think about race conditions and deadlock in asynchronous operations, you gotta do the same here but make sure that your services won’t be used outside of HttpContext

[@Petoj87]

@@RawCoding I'm faily sure it bad practice to not await a task, When you need fire and forget use something like hangfire instead?

[@RawCoding]

What? If you kick off 2 tasks in parallel that share a resource you have to think about concurrency problems, it’s just what happens. Nothing to do with awaiting or c# or hangfire. The point is that with httpcontextaccessor it forces you to think about these problems With hangfire you’ll have to think about different problems Some are essential some are accidental, in the case of the accessor the problem is accidental

[@ivandrofly]

Auth god

[@credirgam4865]

I didn't understand anything :) :_(