feat(erli): reuse an existing Allegro connection's credentials for category access (#1387)

[norbert-kulus-blockydevs]

Closes #1387. Part of epic #1381 (final sub-task).

Summary

Extends the #1384 Erli credentials panel (PR #1401) with a reuse-vs-manual choice for the Allegro app credentials used for category-catalog access: when the operator already has an Allegro connection configured, its clientId/clientSecret can be reused instead of registering a second Allegro app. Matches the approved mockup (both states).

Security: the raw Allegro clientSecret is resolved and copied entirely server-side — it is never serialized into any HTTP response body, and the frontend never sees it.

Architecture note

The initial implementation embedded the reuse-resolution logic (with 'allegro'/allegroClientId/allegroClientSecret literals) directly inside the generic, cross-platform ConnectionService.updateCredentials. That was caught in review as a "platform name leaks into core/host layer" violation and refactored before this PR was opened.

The shipped design instead introduces a new, fully platform-neutral ConnectionCredentialsRewriterPort + ConnectionCredentialsRewriterRegistryService in libs/core/src/integrations/, mirroring the existing ConnectionConfigShapeValidatorPort/ConnectionCredentialsShapeValidatorPort pair. ConnectionService.updateCredentials now just looks up a rewriter by adapterKey and no-ops when none is registered — it has zero knowledge of Allegro or Erli.

All Erli/Allegro-specific logic (resolve reuseAllegroConnectionId → read the source connection's credentials → validate it's an Allegro connection with client credentials configured) lives in ErliAllegroCredentialsRewriterAdapter, registered from a new companion ErliCredentialsRewriterModule (mirrors the existing ErliWebhookProvisioningModule shape) since the adapter needs a NestJS-injected ConnectionPort that's intentionally outside the framework-neutral HostServices bag.

Backend

• libs/core/src/integrations/domain/ports/connection-credentials-rewriter.port.ts — new port
• libs/core/src/integrations/domain/exceptions/connection-credentials-rewrite.exception.ts — new domain exception
• libs/core/src/integrations/infrastructure/adapters/connection-credentials-rewriter-registry.service.ts — new registry
• apps/api/.../connection.service.ts — updateCredentials now dispatches through the registry (generic, no platform knowledge)
• libs/integrations/erli/src/infrastructure/adapters/erli-allegro-credentials-rewriter.adapter.ts — the actual reuse logic
• libs/integrations/erli/src/erli-credentials-rewriter.module.ts — registers the adapter
• HostServices.connectionCredentialsRewriterRegistry threaded through libs/plugin-sdk and all three host-plugin modules (Allegro, PrestaShop, Erli) that build the bag manually

Tenant/ownership note: this codebase has no tenant/organization model — there's no tenantId/organizationId anywhere on Connection. @Roles('admin') on the credentials endpoint is the only access boundary that exists today, applied uniformly across the single-deployment instance. The closest enforceable check is that the reuse-source id must resolve to a real, existing platformType: 'allegro' connection — anything else is rejected. Documented inline in the adapter's JSDoc.

Frontend

ErliCredentialsPanel (apps/web/src/plugins/erli/components/erli-credentials-panel.tsx): when ≥1 active Allegro connection exists, shows a "Reuse credentials from an existing Allegro connection" / "Enter Allegro app credentials manually" radio choice with a connection picker, per the approved mockup. Zero Allegro connections falls back to manual-only entry (today's #1384 behavior) with a notice. The reuse path sends { reuseAllegroConnectionId } and follows the same sequenced, fail-safe-ordered write pattern established in #1401 (credentials first, then the allegroCategoryAccessEnabled config patch).

Tests

• connection.service.spec.ts — generic passthrough/delegation/error-mapping tests against a stub rewriter (no Allegro-specific cases; those moved out)
• erli-allegro-credentials-rewriter.adapter.spec.ts — new, 7 cases (successful reuse, not-found, wrong platform, missing client credentials, blank id, passthrough when absent)
• erli-credentials-panel.test.tsx — zero-connections notice, reuse radio + picker, successful reuse submit (asserts payload never contains the raw secret), manual override still works, reuse-without-selection validation

Quality gate

Full-repo pnpm lint, pnpm check:invariants, pnpm type-check, and pnpm test all green (confirmed independently in an isolated worktree before this PR was opened).

[norbert-kulus-blockydevs]

Review

Overall this is a clean, well-precedented change: pulling the reuse-resolution logic out of ConnectionService into a new ConnectionCredentialsRewriterPort/registry (mirroring the existing shape-validator pair) correctly keeps CORE/host platform-agnostic, and the raw Allegro secret never round-trips through the browser (confirmed by the existing FE test asserting allegroClientSecret never appears in the outbound payload).

IMPORTANT

1. ConnectionCredentialsRewriterPort's own contract is only half-wired. libs/core/src/integrations/domain/ports/connection-credentials-rewriter.port.ts documents the rewrite as happening "on connection create / credential rotation," but ConnectionService.create() (apps/api/src/integrations/application/services/connection.service.ts, ~line 170) validates the raw payload directly and never calls rewriteCredentials - only updateCredentials() does. If reuseAllegroConnectionId were ever submitted through POST /connections (create), it would be persisted verbatim as an unresolved literal instead of being resolved, silently breaking the feature. Not reachable via the shipped FE today (the panel only uses the rotate endpoint), but worth either wiring create() too or narrowing the port's docstring to "credential rotation only."

2. No status check on the reuse-source connection. ErliAllegroCredentialsRewriterAdapter.rewrite() (libs/integrations/erli/src/infrastructure/adapters/erli-allegro-credentials-rewriter.adapter.ts:41-49) checks platformType === 'allegro' and that client credentials exist, but never checks status. The FE picker filters to status: 'active' connections, but that's UI-only, not a backend boundary - a direct API call could reuse credentials from a disabled/error Allegro connection. Worth an explicit status check or a documented rationale for omitting it.

SUGGESTION

3. apps/web/src/plugins/erli/components/erli-credentials-panel.tsx calls useConnectionsQuery({ platformType: 'allegro', status: 'active' }) unconditionally on every render, even when the rotate panel (showRotate) is collapsed. Consider gating with enabled: showRotate so the query only fires when the operator actually opens "Rotate API key."

4. The panel continues (and expands) the file's existing inline-style pattern (style={{ display: 'flex', ... }}) rather than shared classes per docs/frontend-ui-style-guide.md. Not introduced by this PR, but grown by it - worth a follow-up cleanup pass.

Security

No security findings. The design intentionally keeps the raw secret server-side (never echoed in responses, error messages only leak the already-known connection ID/platformType), the authorization boundary (@Roles('admin') on updateCredentials) is unchanged, and the cross-connection credential read isn't a new privilege boundary given OpenLinker's current single-tenant, admin-only access model.

Verdict: approve with changes - resolve or explicitly document #1 and #2 before merge; #3/#4 are optional follow-ups. Naming, layering, DI tokens, and test coverage all follow the documented conventions.

[piotrswierzy]

/pr-review — feat(erli): reuse an existing Allegro connection's credentials for category access (#1387)

Summary

Adds a "reuse an existing Allegro connection's app credentials" path to the Erli credentials panel, resolving the raw clientSecret entirely server-side so it never reaches the browser or any response body. The standout is the architecture: an initial version that embedded 'allegro'/allegroClient* literals in the generic ConnectionService.updateCredentials was caught in review and refactored into a fully platform-neutral ConnectionCredentialsRewriterPort + registry — exactly mirroring the #586/#587 shape-validator pattern. Security-conscious, correctly layered, well-tested. Approve.

Architecture — the platform-leak fix is textbook ✅

• ConnectionService.updateCredentials now dispatches through ConnectionCredentialsRewriterRegistryService.get(adapterKey)?.rewrite() and no-ops when no rewriter is registered — the only allegro/erli mentions in the file are explanatory comments; the code carries zero platform knowledge. This is precisely the CORE↔Integration boundary the docs demand ("no platform name leaks into core/host").
• New surface is correctly placed: port in domain/ports/, exception in domain/exceptions/ (extends Error, sets .name, captureStackTrace — standards-compliant), registry in infrastructure/adapters/, token in integrations.tokens.ts, threaded through HostServices + plugin-sdk + all three host modules. The ErliCredentialsRewriterModule mirrors the existing ErliWebhookProvisioningModule shape (needs a Nest-injected ConnectionPort outside the framework-neutral HostServices bag — the right call).
• All Allegro/Erli logic lives in ErliAllegroCredentialsRewriterAdapter, and it's properly defensive: passthrough when reuseAllegroConnectionId is absent, and it throws ConnectionCredentialsRewriteException on blank id / not-found / non-Allegro platformType / missing source client creds.

Security — verified end-to-end ✅

• Secret never hits a response. @Roles('admin') @Put(':id/credentials') → HttpStatus.NO_CONTENT (empty body); updateCredentials(): Promise<void> resolves the pair, merges it into stored credentials (credentials.update(ref, { credentialsJson })), and returns nothing. The raw clientSecret is read server-side → persisted → never serialized. Matches the architecture-overview baseline ("never return secrets/credentials in API responses").
• reuseAllegroConnectionId is stripped by the rewriter and not persisted — only the resolved concrete allegroClientId/allegroClientSecret land in storage; the log line names the source connection but not the secret.
• FE sends only { reuseAllegroConnectionId } on the reuse path (secret only on the manual path), and the panel test asserts the payload never contains the raw secret. No any anywhere in the diff.

🟢 One forward note (not a blocker) — the reuse surface is bounded only by admin + single-tenant

reuseAllegroConnectionId lets an admin copy any existing Allegro connection's secret into an Erli connection. The PR is honest about this: there's no tenant/org model, so @Roles('admin') + "must resolve to a real platformType:'allegro' connection" is the whole boundary. That's fine today — an admin already has full credential-management authority over every connection in a single-deployment instance, so this is not privilege escalation, and the existence + platform guard blocks garbage ids. The forward risk: when a tenant/organization model eventually lands, this rewriter needs an ownership check (source connection must belong to the caller's tenant), otherwise it becomes a cross-tenant credential-read vector. Worth a one-line TODO/ADR note in the adapter so it's not missed at that point — the JSDoc already flags the absence of tenancy, which is most of the way there.

Tests — strong ✅

Generic service delegation/passthrough/error-mapping (Allegro cases correctly moved out to the adapter spec); adapter spec's 7 cases cover success + every rejection branch (not-found, wrong-platform, missing creds, blank id, absent-passthrough); FE panel covers the zero-connections fallback, reuse radio + picker, the secret-free reuse payload, manual override, and reuse-without-selection validation.

Verdict

✅ Approve — clean platform-neutral refactor of a real boundary violation, server-side secret handling with the correct HTTP contract (admin-only, 204, void), and thorough tests. mergeable_state: clean onto the epic branch. This closes out the #1381 Erli-Allegro epic (plan → client → wiring → FE → credential reuse). Only follow-up is the tenant-ownership check whenever multi-tenancy arrives.