WARNING: THIS SITE IS A MIRROR OF GITHUB.COM / IT CANNOT LOGIN OR REGISTER ACCOUNTS / THE CONTENTS ARE PROVIDED AS-IS / THIS SITE ASSUMES NO RESPONSIBILITY FOR ANY DISPLAYED CONTENT OR LINKS / IF YOU FOUND SOMETHING MAY NOT GOOD FOR EVERYONE, CONTACT ADMIN AT ilovescratch@foxmail.com
Skip to content

Add provider association with specific authentication method #143

@felixarntz

Description

@felixarntz

We already have RequestAuthenticationInterface, with ApiKeyRequestAuthentication currently being the only implementation of that interface.

Since pretty much all cloud providers today require an API key for authentication, we don't need to expand the available implementations just yet.

However, what we should do is to properly set up an association between each provider and which authentication method they use. Today, all our code can simply just assume that a cloud provider needs an API key, which is not a proper solution.

Implementing this should be pretty straightforward. Authentication classes can already provide context about its necessary input, via the getJsonSchema() method. They can also be dynamically instantiated without coupling things to a concrete constructor, via the fromArray() method.

Proposed approach

  • Add a new optional authenticationMethod field / key to ProviderMetadata, which will contain an identifier of an available authentication method.
    • For now, the only possible values will be NONE and API_KEY.
    • As reasonable defaults, use API_KEY if the provider type is CLOUD, and use NONE otherwise.
    • That being said, we should still update all provider implementations to explicitly set those values, as a good example.
  • Add a way to get the authentication class for a given authentication identifier.
    • Either use an enum class, with a custom additional method to get the class name associated with the identifier.
    • Or implement an authentication registry where authentication classes can be registered with an identifier.
    • The latter is probably the proper long-term solution, but we could start with the former to keep things simple for now. It could be iterated on later without breaking changes.
  • Update ProviderRegistry::setRequestAuthenticationForProvider to include a check in the beginning to ensure the given authentication instance is of the class expected by the provider. If not, throw an exception.
  • Update ProviderRegistry::createDefaultProviderRequestAuthentication to look up which class is needed, instead of having ApiKeyRequestAuthentication hard-coded.

Metadata

Metadata

Assignees

No one assigned

    Labels

    [Feature]New feature to highlight in changelogs.

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions