Split connector extra settings per credential path

Registration.ExtraSettings was a single flat list, but the API-key and
client-credentials connect dialogs need different fields whenever a
provider offers both paths, because a different create resolver and a
different driver sits behind each. Replace it with
APIKeyExtraSettings and ClientCredentialsExtraSettings, and split the
GraphQL surface to match so a client cannot render one path's settings
on the other.

This fixes two connectors that could not be connected at all.

1Password declared accountId and region only, which are the
client-credentials shape. The API-key dialog therefore rendered those
two fields, mapAPIKeyExtraSettingToField returned nil for both so
buildExtraFields discarded them, and the SCIM-bridge driver failed on an
empty SCIMBridgeURL. The console already mapped scimBridgeUrl, but no
registration declared that key, so the branch was dead. It now declares
scimBridgeUrl on the API-key path and accountId + region on client
credentials.

Langfuse declared baseUrl as required, but mapAPIKeyExtraSettingToField
had no LANGFUSE case, so buildExtraFields dropped the value the customer
typed and the mutation failed with "langfuseBaseUrl is required". Every
other extra-settings provider had a case. The GraphQL input field, the
settings struct, the probe builder and the driver were all already
correct; only the console mapping was missing.

buildExtraFields now takes the settings list explicitly instead of
reading it off the provider, so each dialog passes its own path's list
and cannot silently iterate the other one.

Register rejects a settings list for a path the provider does not offer,
and an empty or duplicate setting key within one list. A key repeated
across the two lists is allowed: that is how a dual-path provider
declares a setting both dialogs need.

The new resolver tests walk the whole chain the console walks, from the
key a Registration declares through the mutation input field to the
persisted settings struct, so a key renamed on one side and not the
other fails in CI instead of at connect time.

Signed-off-by: Aurélien Sibiril <81782+aureliensibiril@users.noreply.github.com>
This commit is contained in:
Aurélien Sibiril
2026-07-26 15:56:10 +02:00
parent b6a7c9d7c4
commit fb68e98941
37 changed files with 551 additions and 143 deletions

View File

@@ -130,7 +130,20 @@ type ConnectorProviderInfo {
apiKeyManaged: Boolean!
clientCredentialsSupported: Boolean!
oauth2Scopes: [String!]!
extraSettings: [ConnectorProviderSettingInfo!]!
"""
apiKeyExtraSettings lists the per-provider settings the API-key connect
form must render and submit, in render order. Empty when the provider needs
none or has no API-key path.
"""
apiKeyExtraSettings: [ConnectorProviderSettingInfo!]!
"""
clientCredentialsExtraSettings lists the settings the client-credentials
connect form must render and submit. A provider offering both paths
(1Password) returns different fields here than in apiKeyExtraSettings,
because a different settings struct and driver sits behind each — so a
client cannot render one path's settings on the other.
"""
clientCredentialsExtraSettings: [ConnectorProviderSettingInfo!]!
}
type ConnectorProviderSettingInfo {