Passing per-request headers

[mrtoby]

I started to look on how to do authentication and most solutions I see suggest that you pass your JWT token (or similar) in a http header. The HttpClient object is intended to be reused across threads etc, and thus I expect the same for GraphQLHttpClient.

I have seen code examples (somewhere) where DefaultRequestHeaders is configured with a JWT token. This feels really awkward since that is intended for headers that should be common for all requests, e.g. User-Agent and things like that. Not per-user autentication tokens. If you have a service-to-service setup where the service authenticates once, it might make sense to add it in the DefaultRequestHeaders, otherwise not.

In my setup, I will pass per-user authentication tokens and would like to set headers per-request to the GraphQL endpoint. I do not want to use DefaultRequestHeaders since that not would support concurrent use of the HttpClient/GraphQLHttpClient (which is the intended usage pattern of HttpClient) since the DefaultRequestHeaders is a per-client global setting.

My suggestion: Allow to configure http request headers per request somehow.

Perhaps by making a subclass of GraphQLRequest that allow this. The GraphQLHttpClient should still support executing requests of the type GraphQLRequest, but if a subclass is used, it will consider the http-specific settings for this particular request.

Side note: A more pure solution that is transport independent would be to add a token argument to all queries and mutations that need authentication. This would be such a mess though... It could be cleaned up by using variables, but still really messy and very easy to miss passing the token to one of the 20 different queries/fields being invoked.

[deinok]

Perhaps by making a subclass of GraphQLRequest that allow this. The GraphQLHttpClient should still support executing requests of the type GraphQLRequest, but if a subclass is used, it will consider the http-specific settings for this particular request.

I think that this is the best way to go. This addition should come with v2.0.0

[mrtoby]

I'm getting to the point where I really need this to be able to continue, otherwise I will have to find another solution. Could I help you out somehow to make this happen?

[deinok]

I think that the best solution for now is have a GraphQLClient for every client. The GraphQLClient is tries to be transport independent. Probably not the most performant solution but it should work and in most cases you won't notice any performace issues.

[fireflymusti]

Hi @deinok
I was going throw this issue and wanted to know If there is any update on it.

I have prerelease version of graphql-client from Nuget and want to add Authentication Header to GraphQLHttpClient to get subscription data of my client.

Adding authentication headers as following:

using (var graphQLHttpClient = new GraphQLHttpClient(webSocketServer)) { graphQLHttpClient.DefaultRequestHeaders.Add("Authorization", $"bearer {token}"); subscriptionResult.OnReceive += (res) => { Console.WriteLine(res.Data.messageAdded.content); }; .... }

I am getting "Unable to connect to the remote server". If I test it with some other server and without headers it works fine.
Is it possible to add headers using graphQLHttpClient?
BR

[MaorDavidzon]

Is there any update on that issue?

It can be very useful when using DI

[sungam3r]

As @deinok said.
In my own graphql C# client generator I create a new client instance under the hood when I need to use custom headers. I do not use HttpClient.DefaultRequestHeaders

[don01001000]

Would it be possible for GraphQLHttpClient to have a client-level Action<HttpRequestMessage> or Action<HttpRequestHeaders> that gets invoked just before a request is sent? That would allow for headers to be modified just prior to the request being sent but have the code for modifying the headers be separate from the code using the client. This could help abstract away the authorization mechanism. A similar effect could be achieved with a pattern other than callbacks. As @MaorDavidzon said, this would be great for DI. Thanks!

[sungam3r]

You can set GraphQLHttpClientOptions.HttpMessageHandler to your handler.

  public class MyHandler : DelegatingHandler
    {

        public MyHandler(HttpMessageHandler inner = null) : base(inner ?? new HttpClientHandler()) { }

        protected override async Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
        {
            request.Headers.Authorization = ...;

            return await base.SendAsync(request, cancellationToken);
        }
    }

Through the constructor you can pass the data source for authorization.

Also regarding this my comment:

As @deinok said.
In my own graphql C# client generator I create a new client instance under the hood when I need to use custom headers. I do not use HttpClient.DefaultRequestHeaders

Since then, a time has passed and in fact I use a mixed approach now - both my own handler (like example above) and setting the HttpClient.DefaultRequestHeaders.

[don01001000]

I appreciate your quick reply, @sungam3r! I've noticed if I use:

myGraphQLClient.Options.HttpMessageHandler = new MyHandler();

Even if the first thing that's done, it's not used. However, if I pass in a GraphQLClientOptions object to the GraphQLClient constructor with the property set, it works. Is that expected?

I'm trying to accomplish this with GraphQL.Client 1.0.3 to give a little context.

Thanks!

[sungam3r]

Before discarding this package, I used 2.0.0-alpha.3 version and GraphQLHttpClient.