Contrib.social

Unify and clarify how to write "api-key" vs. "api_key" vs. "apikey" and stick to (Swagger) standards?

Open on Drupal.org →
Created on 3 April 2024, 3 months ago
Updated 28 May 2024, about 1 month ago

Problem/Motivation

The code currently has different wordings for the api_key / apikey / api-key which is super confusing.

The module page for example says:

3) Making a request to the endpoint with a key
The module will look for either a request parameter or header (depending on how the module was configured) called api-key and look to compare this value against the key defined for the endpoint. Any requests without this value or with an invalid value will be blocked.

The implementation on the other hand is:

  /**
   * Retrieve key from request.
   *
   * @param \Symfony\Component\HttpFoundation\Request $request
   *   The request object that the service will respond to.
   *
   * @return bool
   *   True if api key is present
   */
  public function getKey(Request $request) {
    // Exempt edit/delete form route.
    $route_name = $this->currentRouteMatch->getRouteName();
    if (str_contains($route_name ?? '', 'entity.api_key')) {
      return FALSE;
    }

    $form_api_key = $request->request->get('api_key');
    if (!empty($form_api_key)) {
      return $form_api_key;
    }

    $query_api_key = $request->query->get('api_key');
    if (!empty($query_api_key)) {
      return $query_api_key;
    }

    $header_api_key = $request->headers->get('apikey');
    if (!empty($header_api_key)) {
      return $header_api_key;
    }
    return FALSE;
  }

Steps to reproduce

Proposed resolution

Stick to standards and for the future use the Swagger defaults: https://swagger.io/docs/specification/authentication/api-keys/

Additionally (or alternatively) make the other variations configurable. This could also be a good way to keep the old keys for existing implementations.

Remaining tasks

  1. Decide which key to use by default
  2. Decide to make it configurable
  3. Implement
  4. Release, probably as new major release?

User interface changes

API changes

Data model changes

📌 Task
Status

Active

Version

3.0

Component

Code

Created by

🇩🇪Germany Anybody Porta Westfalica

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @Anybody
  • Comment 3 months ago →
    🇩🇪Germany markaspot

    Thank you for looking into this. I suspect the module's description might be based on version 7.x, prior to merging it with a similar module resulting in the 3.x branch. However, I’m not entirely certain about this. I'm wondering if the api-key parameter, which could have been relevant in the D7 version is still relevant. Anyway I am open to a configurable option, but I think this would need a new maintainership, as my time constraints prevent me from keeping this module alive. Sure it would be easy to edit the module description, if it's just a typo.

  • Comment about 1 month ago →
    🇩🇪Germany Anybody Porta Westfalica

    @Maintainers: I'd very much like to read your feedback here.

    This is my suggestion:
    1. Make "api_key" the default for new installations (for all methods) but keep the old key for existing sites
    2. Make the key configurable (per method)

    What do you think?

    This way it would be self-documenting in docs and we'd have a very flexible solution.

contrib.social Blog FAQ Discussions
Production build 0.69.0 2024