IRaftHttpCluster set custom http request headers?

[Arkensor]

Hello,

I would like to add a custom header to all http requests made by the IRaftHttpCluster to validate an api key. Otherwise people could just call the internal endpoints of the raft cluster and mess with it (e.g. calling fake election to disrupt operations)?

I found some information on it here but I do not see how I could use that to access the requests and set headers.

Does someone have an idea how to achieve this?

Thanks!

[sakno]

You can't.. and you really don't need this. Prior to 4.x, the library had two Raft hosting modes: embedded and hosted. In embedded mode, Raft was hosted on the same WebHost as main application. In hosted mode, separated WebHost was created. In 4.x I removed these two modes for simplicity. Actually, there are a lot of ways to achieve what you want:

1. You can manually register more than one WebHost in your application and configure it for Raft. It means that you can host Raft-related stuff on the separated port which is not visible externally
2. Configure HTTP reverse-proxy or load balancer in a way that prevents access to Raft-specific endpoints
3. Implement IP whitelist as ASP.NET Core middleware

These things are not related directly to Raft. That's why they are not included in the library.

[Arkensor]

I must say that this does not really satisfy me. You can't always lock the raft mechanism behind closed doors. If you deploy an application on cloud providers like azure or Heroku, you get a single http(s) connection into your app and that is all you have available. So if you want to use http raft there it must be exposed.
Even when you wanted to do an IP whitelist ... you can't trust that an IP source was the same requester. Someone behind that is behind NAT could wait for the original cluster service to get accepted by the remote leader and after that send his own requests. The origin IP will be the same for both ...

You use an HTTPClient and even give the option to provide your own socket factory ... we should have the option to just set a dictionary of default headers.

Normally I would just inherit from any of the library classes that I want to adapt for my use case and override what I need to. But everything is locked behind internal, private and or sealed classes. This is giving me a very hard time.

One suggestion apart from being able to add your own headers: Maybe requests are simply ignored from unknown people? Only endpoints who are in your cluster are allowed to communicate with you? If you control who is able to issue AddMember you can do all the security you want there. And once that is done all members can trust each other.
e.g.: new instance wants to join. Adds himself and the remote leader into his local cluster configuration and asks for the join via an external way of communication (e.g. rest api with auth headers). The remote leader validates the requests and accepts him into the cluster. The leader calls AddMember and any request/response from and with the new instance is allowed from there on. Even the first http request issued to the new instance for replication could already be trusted because the leader knows him already and the instance that wanted to join knew locally that he will accept the leader he just asked to join as a trust-able source.
Maybe this idea is flawed ... I don't know. It would be easier if we just had headers ;)

[sakno]

If you deploy an application on cloud providers like azure or Heroku, you get a single http(s) connection into your app and that is all you have available.

Not exactly. In Azure, you can easily configure load balancer or reverse-proxy for your app and tell which ports must be exposed outside. With Kubernetes in the cloud it is more easier. You can configure Services and app ports exposed by each container and the ports available for Ingress Controller. The same setup is used for databases. DB server exposes many ports for internal purposes: replication, consensus etc. But for management console and client connections the server uses different port.

As for IHttpMessageHandlerFactory - this is the right way to inject any header values. Multiple message handlers can be combined into a single pipeline. This is the official extension point. Here is one of the delegating handlers from standard .NET library.

[Arkensor]

I have no idea if this is a "clean" solution or could otherwise be optimized but I wanted to share my working approach if others ever need it. @sakno Thank you for the hint with the delegating handlers! I only looked at the SocketsHttpHandler and tried to make it add my headers ... I did not really understand the concept of how the IHttpMessageHandlerFactory can be used.

    public class RaftClientHandlerFactory : IHttpMessageHandlerFactory
    {
        public HttpMessageHandler CreateHandler(string name)
        {
            if (name == "raftClient") return new RaftMessageHandler(new SocketsHttpHandler { ConnectTimeout = TimeSpan.FromMilliseconds(AppSettings.ConnectionTimeout) });

            return new SocketsHttpHandler();
        }

        public class RaftMessageHandler : MessageProcessingHandler
        {
            public RaftMessageHandler(HttpMessageHandler innerHandler) : base(innerHandler)
            {
            }

            protected override HttpRequestMessage ProcessRequest(HttpRequestMessage request, CancellationToken cancellationToken)
            {
                request.Headers.Add("X-Api-Key", "XXX-XXX-XXX-XXX-XXX");

                return request;
            }

            protected override HttpResponseMessage ProcessResponse(HttpResponseMessage response, CancellationToken cancellationToken)
            {
                return response;
            }
        }
    }

[sakno]

Your example is correct. But you need to check the name of the requested handler. Otherwise, you'll add the delegating handler to all HttpClients in your application.

[Arkensor]

I thought about it, but I am not sure how to "use the default" if its not raft that is requesting this ...

@sakno What should be returned for everything else?

[sakno]

One of the handlers providing transport services: SocketsHttpHandler, HttpClientHandler, or WinHttpHandler.

[Arkensor]

My question was going towards whom of the 3 to choose. According to the docs the default would be SocketsHttpHandler since net core 2.1 or later.

I updated my example above :)