You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
DelegatingHandlers have odd behavior where they get cached across requests, and it can be very difficult to register the authorization properly. User A makes request to service A, this service uses Refit to call to service B with a token for User A. User B goes through same code path, and if the handler is still cached, we will get the token for User A -> Service B even though user B is the one making the request.
Describe the solution you'd like
The RefitSettings allows us to have a simple Func for the auth header, but this is global and cannot rely on a scoped service (such as the current user information). If there was a way to have this Func also take an IServiceProvider parameter, that i could then resolve a scoped token out of.
We try to use a handler like below, but because of weirdness with DI scopes, this sometimes fails. I have tried to make the ITokenProvider be based on AsyncLocal<string>, but we were still seeing this behavior from time to time.
publicclassAuthHeaderHandler:DelegatingHandler{privatereadonlyIServiceProvider_sp;publicAuthHeaderHandler(IServiceProvidersp){_sp=sp;}protectedoverrideasyncTask<HttpResponseMessage>SendAsync(HttpRequestMessagerequest,CancellationTokencancellationToken){stringtoken= _sp.GetRequiredService<ITokenProvider>().GetToken();//sometimes this token^ is still for User A even though the request is made by User B
request.Headers.Authorization =new AuthenticationHeaderValue("Bearer", token);returnawaitbase.SendAsync(request, cancellationToken).ConfigureAwait(continueOnCapturedContext:false);}varbuilder= services
.AddRefitClient<IMyApi>().ConfigureHttpClient(ConfigureHttpClient).AddHttpMessageHandler<AuthHeaderHandler>();}
Describe suggestions on how to achieve the feature
Someone who knows the ins and outs of DelegatingHandlers and how to configure the handler properly can make a working implementation and add an extension into Refit to make it a one-liner for those who have this situation.
Additional context
I believe this to be a very common use case that could be helpful to many others. We use Refit to connect all our microservices together and we need to be absolutely certain that each request is being sent with the right auth header, else we have a security issue.
The text was updated successfully, but these errors were encountered:
I guess it depends on how the ITokenProvider is implemented. If you're using IHttpContextAccessor to get the current request's token, your message handler approach should be fine, e.g:
Is your feature request related to a problem? Please describe.
DelegatingHandler
s have odd behavior where they get cached across requests, and it can be very difficult to register the authorization properly. User A makes request to service A, this service uses Refit to call to service B with a token for User A. User B goes through same code path, and if the handler is still cached, we will get the token for User A -> Service B even though user B is the one making the request.Describe the solution you'd like
The
RefitSettings
allows us to have a simpleFunc
for the auth header, but this is global and cannot rely on a scoped service (such as the current user information). If there was a way to have thisFunc
also take anIServiceProvider
parameter, that i could then resolve a scoped token out of.Example:
Describe alternatives you've considered
We try to use a handler like below, but because of weirdness with DI scopes, this sometimes fails. I have tried to make the
ITokenProvider
be based onAsyncLocal<string>
, but we were still seeing this behavior from time to time.Describe suggestions on how to achieve the feature
Someone who knows the ins and outs of
DelegatingHandlers
and how to configure the handler properly can make a working implementation and add an extension into Refit to make it a one-liner for those who have this situation.Additional context
I believe this to be a very common use case that could be helpful to many others. We use Refit to connect all our microservices together and we need to be absolutely certain that each request is being sent with the right auth header, else we have a security issue.
The text was updated successfully, but these errors were encountered: