0

I want to make a httpClient wrapper that is able to use a predefined set of authentification methods: basic, digest, token (oauth), ntlm just to name a few that I will have to implement.

My approach to this was inspired by the Apache implementation of Authentication Schemes in java, which is creating an Auth class, and adding it to the http client, which makes it very easy for the user to assign a authentification method:

main.cpp:

ApiClient api_client;

ApiClient::api_client_config_t config = {};
config.host = "https://en52ztuigmv6x.x.pipedream.net";
config.auth = std::unique_ptr<AuthMethod>
    (new AuthMethodBasic("foo", "bar"));

api_client.init(std::move(config));     
api_client.get("/anything");

Though, to make this work, on the backend, I've had to create forward declarations and friend all derived classes of AuthMethod that will need access to the ApiClients internals.

api_client.h:

class AuthMethod;
class AuthMethodInternal;
class AuthMethodToken;
class AuthMethodNtlm;

class ApiClient {
friend class AuthMethod;
friend class AuthMethodInternal;
friend class AuthMethodToken;
friend class AuthMethodNtlm;

Reading through a answer on friend inheritance I do seem to follow those requirements, specifically:

Any change in the internal representation of a class will require a modification to anything that is dependent on that representation. Thus all members of a class and also all friends of the class will require modification.

As I'm the only one able to create new authentication methods, or modify the internals, a change in the internal design of ApiClient wouldn't be an issue. But there also seem to be opinions about friend inheritance being a sign of bad design.

At this point I've decided to ask for suggestions to see if there is a different design architercure I might be able to use, as this current design is starting to stink.

My requirements are quite simple honestly:

  • Modular, so I can easily add new authentication methods - (this means they would probably have to be self-contained, so that it doesn't require modifying the base ApiClient code)

Reasoning behind AuthMethod having to access the internals of ApiClient:

  • Only the client knows the host url, port, certificate, etc
  • By the time authentication kicks in, the ApiClient has already created a httpClient instance handle, and properly configured it. Creating another one would be a waste of resources (which on a embedded platform is double not good)
2
  • How private/internal is this information needed by the AuthMethod? Is it conceivable to create an interface that AuthMethod uses and ApiClient provides with public methods for the required information? Jul 17 '20 at 13:43
  • @BartvanIngenSchenau Not really, I guess I'll have to look into a redesign - I probably have to do that anyways because I've realized another flaw (the authentication coomunication between the client and the server is likely gonna send random events to the user code, as they use the same handle) - which could be solved with clever state machines, but that's a little over the top I think. I'll likely just have the Auth class later give up a unique_ptr containing the handle, after it's done its authentication.
    – niraami
    Jul 20 '20 at 6:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.