Name der Anmeldedaten mit automatischer Inkrementierung scheint für benutzerdefinierte Anmeldedaten global zu sein, aber pro Person für einige integrierte (OpenAI)

Fragen
1

{“n8n-workflow”: “^1.120.13”}

Ich beobachte ein inkonsistentes Verhalten bei der Benennung von Anmeldedaten in n8n und möchte bestätigen, ob dies erwartet ist.

Was ich beobachte

  • Für meinen benutzerdefinierten Anmeldedatentyp (myApi) werden neue Anmeldedaten global über die gesamte Instanz automatisch benannt:

    • Benutzer A erstellt persönliche Anmeldedaten: MyApi Account, MyApi Account 2

    • Benutzer B (der die persönlichen Anmeldedaten von Benutzer A nicht sehen kann) erstellt eine und erhält: MyApi Account 3

  • Aber z. B. für OpenAI-Anmeldedaten scheint der Zähler persönlich/projektgebunden zu sein (er wird nicht auf die gleiche Weise von den Anmeldedaten anderer Benutzer in der gleichen Instanz fortgesetzt).

Warum dies verwirrend ist

Die Sichtbarkeit der Anmeldedaten ist persönlich/projektbasiert, aber das generierte Namenssuffix für meinen benutzerdefinierten Typ scheint einen globalen Zähler zu verwenden. Dies macht die Benennung auch dann “undicht” zwischen Benutzern wirken, obwohl die Anmeldedaten nicht gemeinsam genutzt werden.

Frage

  • Ist dieser Unterschied zwischen integrierten (z. B. OpenAI) und benutzerdefinierten Anmeldedatentypen erwartet?

  • Gibt es mehrere Abläufe zur Anmeldedatenerstellung/Namensgenerierung in n8n, die dies erklären?

  • Gibt es eine Möglichkeit für einen benutzerdefinierten Anmeldedatentyp, die Namensgenerierung pro Benutzer/pro Projekt statt globales Suffixing zu verwenden?

"n8n-workflow": "^1.120.13"

3

Willkommen in der n8n Community @Jankaz
Hast du überprüft, ob die OpenAI-Anmeldedaten im gleichen Workflow wie deine benutzerdefinierte Anmeldedaten erstellt werden (persönliches Projekt vs. freigegebenes Projekt vs. globales Projekt des Besitzers)?
Ich bin der Ansicht, dass dein Problem im internen Erstellungs-/Benennungspfad liegt, der verwendet wird. Kannst du ein einfaches Reproduktionsbeispiel teilen, das benutzerdefinierte Anmeldedaten mit OpenAI-Anmeldedaten vergleicht, einschließlich Projekt, Benutzerrolle, generierte Namen und Nummerierungsverhalten zwischen Benutzern?

4

Ich habe die Anfragen im Netzwerk überprüft und beide verwenden https://n8n.stg.olx.org/rest/credentials mit der gleichen Payload-Struktur. Beide mit der gleichen projectId. Der einzige Unterschied ist, dass die Payload für OpenAI ein zusätzliches Feld uiContext: "credentials_list" hat, aber ich glaube, das ist nicht der Fall

5

MyApi.credentials.ts

export class MyApi implements ICredentialType {
  name = "myApi";

  displayName = "My API";

  properties: INodeProperties[] = [
    {
      displayName: "Platform Base URL",
      name: "baseUrl",
      type: "string",
      default: "http://myapi.com",
      placeholder: "http://myapi.com",
      required: true,
      hint: "Klicken Sie auf `Speichern`, um sich zu authentifizieren.",
      description: "",
    },
    {
      displayName: "Secret",
      name: "adminToken",
      type: "hidden",
      typeOptions: {
        password: true,
      },
      default: "",
      description:
        "Wird durch n8n-Anmeldedatenvervollständigung gefüllt.",
    },
  ];

  test: ICredentialTestRequest = {
    request: {
      method: "GET",
      baseURL: "={{$credentials.baseUrl}}",
      url: "/health",
    },
  };
}


import type {
  ICredentialDataDecryptedObject,
  ICredentialTestRequest,
  ICredentialType,
  IHttpRequestOptions,
  INodeProperties,
} from 'n8n-workflow';

export class OpenAiApi implements ICredentialType {
  name = 'openAiApi';

  displayName = 'OpenAI';

  documentationUrl = 'openai';

  properties: INodeProperties[] = [
   {
    displayName: 'API-Schlüssel',
    name: 'apiKey',
    type: 'string',
    typeOptions: { password: true },
    required: true,
    default: '',
   },
   {
    displayName: 'Organisations-ID (optional)',
    name: 'organizationId',
    type: 'string',
    default: '',
    hint: 'Nur erforderlich, wenn Sie mehreren Organisationen angehören',
    description:
     "Für Benutzer, die mehreren Organisationen angehören, können Sie festlegen, welche Organisation für eine API-Anfrage verwendet wird. Die Nutzung dieser API-Anfragen wird mit dem Abonnementkontingent der angegebenen Organisation verrechnet.",
   },
   {
    displayName: 'Basis-URL',
    name: 'url',
    type: 'string',
    default: 'https://api.openai.com/v1',
    description: 'Standard-Basis-URL für die API überschreiben',
   },
   {
    displayName: 'Benutzerdefinierten Header hinzufügen',
    name: 'header',
    type: 'boolean',
    default: false,
   },
   {
    displayName: 'Header-Name',
    name: 'headerName',
    type: 'string',
    displayOptions: {
     show: {
      header: [true],
     },
    },
    default: '',
   },
   {
    displayName: 'Header-Wert',
    name: 'headerValue',
    type: 'string',
    typeOptions: {
     password: true,
    },
    displayOptions: {
     show: {
      header: [true],
     },
    },
    default: '',
   },
  ];

  test: ICredentialTestRequest = {
   request: {
    baseURL: '={{$credentials?.url}}',
    url: '/models',
   },
  };

  async authenticate(
   credentials: ICredentialDataDecryptedObject,
   requestOptions: IHttpRequestOptions,
  ): Promise<IHttpRequestOptions> {
   requestOptions.headers ??= {};

   requestOptions.headers['Authorization'] = `Bearer ${credentials.apiKey}`;
   requestOptions.headers['OpenAI-Organization'] = credentials.organizationId;

   if (
    credentials.header &&
    typeof credentials.headerName === 'string' &&
    credentials.headerName &&
    typeof credentials.headerValue === 'string'
   ) {
    requestOptions.headers[credentials.headerName] = credentials.headerValue;
   }

   return requestOptions;
  }
}
6

@Jankaz
Nach dem Backend-Code scheint es, dass POST /rest/credentials den Namen beibehält, der in der Payload empfangen wird. Daher würde ich die Namenserzeugung im Frontend vor dem Senden der Anfrage untersuchen. Wenn OpenAI und die benutzerdefinierte Anmeldung bei demselben Endpunkt mit derselben projectId ankommen, aber bereits mit unterschiedlichen Namen, liegt der Unterschied wahrscheinlich im UI-Fluss, der den standardmäßigen Credential-Namen berechnet, nicht in der save()-Funktion des Backends.

7

Danke – ich stimme zu, dass POST `/rest/credential` einfach den bereitgestellten Namen speichert.
In Netzwerk-Traces rufen sowohl OpenAI als auch benutzerdefinierte Credentials `GET /rest/credentials/new?name=…` vor POST auf.
Die Benennung scheint also durch (a) Frontend-Basisname + (b) Backend-Eindeutigkeitsgenerierung in /credentials/new bestimmt zu werden.
Dies deutet darauf hin, dass der Unterschied aus dem Matching vorhandener Namen für jedes Präfix (OpenAI account% vs GAIP account%) resultiert, nicht aus save() oder uiContext.

8

Also.. wo liegt die Schwierigkeit darin, die Anmeldedaten umzubenennen? :slight_smile:

Ich arbeite seit etwa 4 Jahren mit n8n und habe beobachtet, dass das Beibehalten des Basisnamens später zu Problemen beim Aktualisieren von Anmeldedaten oder beim Bestimmen, was was ist, führt

9

Es gibt keine Schwierigkeiten, aber es ist verwirrend

10

Das ist normal @Jankaz, wenn du erst mal deine Art gefunden hast, die Frage zu verstehen, wird es einfacher. Es ist nicht etwas Konfigurierbares, sie sind visuell einfach unterschiedlich.

Ich habe keinen Parameter gefunden, um die Logik der automatischen Namensgenerierung zu ändern

Die Trennung nach Benutzer/Projekt existiert auf der Ebene der Berechtigung und Sichtbarkeit von Anmeldedaten über RBAC/Projects, aber das bedeutet nicht, dass der automatische Namenszähler auch auf Projektebene begrenzt ist. Die RBAC-Dokumentation spricht über den Zugriff auf Workflows und Anmeldedaten pro Projekt, nicht über den Benennungsalgorithmus.

Wie in dem Thread vorgeschlagen, ist die Lösung, die Anmeldedaten manuell mit Projekt/Benutzer im Namen zu benennen.