Apollo-link-rest: Erlauben Sie die Angabe von "Headern" pro Endpunkt

Erstellt am 5. Feb. 2019  ·  11Kommentare  ·  Quelle: apollographql/apollo-link-rest


Ich denke, es sollte möglich sein, exklusive Header pro Endpunkt anzugeben.

Beispiel: Ich habe die WordPress-REST-API und die WooCommerce-REST-API (v2 und v3) als meine verschiedenen Endpunkte konfiguriert. Daher sollte es möglich sein, für jeden Endpunkt unterschiedliche Autorisierungsheader bereitzustellen.

enhancement💡 feature help wanted 🛠

Hilfreichster Kommentar

@paulpdaniels Dies wäre ein Beispiel, in dem ich die WP REST-API mit dem Autorisierungsheader als Standardendpunkt und die WooCommerce REST-APIs v2 und v3 als separate Endpunkte verwende - v3 erfordert eine Autorisierung und v2 nicht:

import { camelCase, snakeCase } from 'lodash';
import { RestLink } from 'apollo-link-rest';

if (typeof window === 'undefined') {
  global.btoa = str => Buffer.from(str).toString('base64');
}

const restLink = new RestLink({
  uri: 'https://example.com/wp/v2',
  headers: {
    authorization: `Basic ${btoa('client_key:secret_key')}`,
  },
  endpoints: {
    'wc-v2': {
      uri: 'https://example.com/wp-json/wc/v2',
      headers: {
        authorization: undefined,
      },
    },
    'wc-v3': {
      uri: 'https://example.com/wp-json/wc/v3',
      headers: {
        authorization: `Basic ${btoa('another_client_key:secret')}`,
      },
    },
  },
  fieldNameNormalizer: camelCase,
  fieldNameDenormalizer: snakeCase,
});

Alle 11 Kommentare

Guter Punkt! Möglicherweise sollten wir zulassen, dass unsere anfängliche Header-Konfiguration jedes Mal ein Header / Hash oder eine Funktion ist, die ausgeführt wird? @efoken @paulpdaniels

Es macht Sinn, obwohl ich dachte, dass es jetzt so funktioniert, aber ich glaube, ich habe mich nicht mit einem Problem befasst, bei dem mehrere Ressourcen mit unterschiedlichen Header-Anforderungen vorhanden sind.

@efoken Haben Sie ein Beispiel dafür, wie Sie es verwenden möchten? Nur um ein Gefühl dafür zu bekommen, wie ein typischer Anwendungsfall aussehen würde.

@paulpdaniels Dies wäre ein Beispiel, in dem ich die WP REST-API mit dem Autorisierungsheader als Standardendpunkt und die WooCommerce REST-APIs v2 und v3 als separate Endpunkte verwende - v3 erfordert eine Autorisierung und v2 nicht:

import { camelCase, snakeCase } from 'lodash';
import { RestLink } from 'apollo-link-rest';

if (typeof window === 'undefined') {
  global.btoa = str => Buffer.from(str).toString('base64');
}

const restLink = new RestLink({
  uri: 'https://example.com/wp/v2',
  headers: {
    authorization: `Basic ${btoa('client_key:secret_key')}`,
  },
  endpoints: {
    'wc-v2': {
      uri: 'https://example.com/wp-json/wc/v2',
      headers: {
        authorization: undefined,
      },
    },
    'wc-v3': {
      uri: 'https://example.com/wp-json/wc/v3',
      headers: {
        authorization: `Basic ${btoa('another_client_key:secret')}`,
      },
    },
  },
  fieldNameNormalizer: camelCase,
  fieldNameDenormalizer: snakeCase,
});

Gibt es Neuigkeiten zu diesem Thema? Ich bin in einer Situation, in der ich Rest-Link verwende und einen eigenen Endpunkt habe, für den eine Authentifizierung erforderlich ist, und einen anderen Endpunkt eines Drittanbieters, für den ein Schlüssel erforderlich ist.

Gibt es Beispiele dafür, wie man das jetzt macht?

Ich habe auch eine Situation, in der ich auf einigen Endpunkten einen Autorisierungsheader benötige, auf anderen jedoch nicht. Ich kann keinen Weg finden, dies zu erreichen.

Wurde daran gearbeitet? Ich habe eine Situation, in der ein Endpunkt eine Basisauthentifizierung und ein anderer eine Trägerauthentifizierung benötigt

Hat jemand schon eine Lösung dafür gefunden?

Irgendeine Problemumgehung dafür? Ich bin auch in einer Situation, in der ich Header für verschiedene Endpunkte anpassen muss.

Wurde diesbezüglich ein Update durchgeführt? Derzeit wird an einem Projekt gearbeitet, für das für jeden Endpunkt unterschiedliche Authentifizierungen und Header erforderlich sind. Gibt es eine Problemumgehung dafür?

Sie können eine customFetch-Implementierung bereitstellen, die die Ziel-URL analysiert und Header basierend auf einem URL-Präfix einfügt / anfügt. Dies ist heute möglich.

Bitte geben Sie an, ob diese Problemumgehung für Sie nicht funktioniert.

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen