/** * Public API for the linkAuth pure engine. * * `resolveAuthenticatedUrl(url, config)` is the single entry point per design * §6: select the first provider whose `match.host` claims the URL, run its * rewrite pipeline, resolve a token, build the auth headers, and return * everything the caller needs to issue an authenticated fetch. * * Three outcomes: * - `{ fetchUrl, headers }` — ready to fetch (provider claimed, * rewrite matched, token resolved) * - `{ outcome: 'unsupported' }` — no provider claims the host, OR * host matched but no rewrite did * (per §4: "the provider does not * claim the URL for rewriting") * - `{ outcome: 'unverified', reason }` — claimed and rewrote, but no token * source resolved a non-empty value * * Per design issue #113 §6. */ import { type TokenResolutionDeps, type TokenSource } from './resolve-token.js'; import { type RewriteRule } from './rewrite.js'; import { type ProviderMatch } from './select-provider.js'; export interface ProviderAuth { readonly headers: Record; } /** * Optional content-fetch header overrides (design issue #113 §6.2). * * Health-check and content retrieval often need different `Accept` (or other) * headers. The canonical example: GitHub's `application/vnd.github+json` * returns 200 for any size but omits bytes >1 MiB, while * `application/vnd.github.raw` streams the bytes inline. The provider declares * `auth.headers` for health-check and an optional `fetch.headers` for content * retrieval. Both are templated against the same context (URL captures + token). */ export interface ProviderFetch { readonly headers: Record; } export interface ProviderCheck { readonly method: 'GET' | 'HEAD'; readonly aliveStatus: readonly number[]; readonly notFoundMeaning: 'ambiguous' | 'dead'; } export interface Provider { readonly match: ProviderMatch; readonly rewrite: readonly RewriteRule[]; readonly auth: ProviderAuth; /** * Optional — present when a provider needs different headers for content * retrieval than for health-check. Absent for hosts where one header set * does both jobs. */ readonly fetch?: ProviderFetch; readonly token: readonly TokenSource[]; readonly check: ProviderCheck; } export interface LinkAuthConfig { readonly providers: readonly Provider[]; /** * Optional content-cache config (consumed by the slice-3 content-fetch * primitive, not by the engine itself). The engine stays stateless; this * field rides along on the config object so the primitive doesn't need a * second source of truth. */ readonly cache?: { readonly ttlMinutes?: number; }; } export type ResolveOutcome = { readonly fetchUrl: string; readonly headers: Record; /** * Expanded fetch-mode headers, only present when the provider declared * a `fetch` block. Templated against the same context as `headers` * (URL captures + resolved token), so callers do not need to re-resolve * the token to send these. Per §6.2 — content-fetch consumers send * these instead of (or merged over) `headers` for the request body. */ readonly fetchHeaders?: Record; /** * The matched provider's `check` block, passed through so the post-fetch * classifier (in `packages/resources`) can route status codes to outcomes * without re-running `selectProvider`. Reading this from the engine — * rather than asking the validator to re-derive it — keeps the * provider-match decision in exactly one place. */ readonly check: ProviderCheck; } | { readonly outcome: 'unsupported'; } | { readonly outcome: 'unverified'; readonly reason: string; }; /** * Resolve an authenticated fetch plan for `url` against the configured providers. * * @param deps - Optional dependency injection for token resolution (`env` map * + `runCommand`). Production callers omit this; tests supply mocks. */ export declare function resolveAuthenticatedUrl(url: string, config: LinkAuthConfig, deps?: Partial): ResolveOutcome; //# sourceMappingURL=resolve.d.ts.map