6 Commits

Include renames

Author	SHA1	Message	Date
admin	3279fa0533	fix(lint): eslint-undantag på rätt rader — json:any i graph-adapter + require-fixtures ... eslint-disable-next-line gällde nästa rad; json:any-linen behövde eget undantag. npm run lint: 0 errors (8→0). 1141/1141.	2026-09-29 12:50:06 +02:00
admin	1b6140a16a	fix(lint): rotfelsa ärvd lint-skuld — graph-adapter + p0-tester (blockerade #128) ... Parallellsessions-merge lämnade 12 eslint-errors på main (no-explicit-any i graph-mailbox-adapter + 2 p0-tester). Graph-JSON:n är genuint ostrukturerad — medveten, avgränsad eslint-undantag med skäl (DoD §13); p0-testerna typade med Record/cast. Lint 0 errors; tsc grön; 1141/1141.	2026-09-29 12:31:34 +02:00
adminandClaude Sonnet 5	4caf122129	fix(security): add SSRF guard to Fabric/OneLake adapter's sqlEndpoint ... connection_config.sqlEndpoint on POST /api/0pt/sources/{sourceId}/query was passed straight from the request body to the mssql TDS driver as the outbound connection target, with only its http(s):// scheme stripped — no hostname allowlist or private/loopback/link-local/cloud-metadata guard. This route already requires a Zitadel bearer token + tenant match (P014 tenant guard), so this was not anonymously exploitable, but it is the exact SSRF shape found and exploited-in-principle elsewhere in this estate tonight (press0), so it's worth closing as defense-in-depth. Adds src/lib/security/ssrf-guard.ts: resolves the endpoint's hostname and rejects any address in a private/loopback/link-local/cloud-metadata/ unspecified range (RFC1918, 127.0.0.0/8, 169.254.0.0/16 incl. the 169.254.169.254 metadata address, ::1, fc00::/7, fe80::/10, IPv4-mapped IPv6), failing closed on DNS resolution errors. The range-check logic is ported 1:1 from press0's src/lib/security/ssrf-guard.ts built the same night for the same bug class against a fetch()-based URL there; this module's surface differs because sqlEndpoint is a bare host[:port], not a fetchable URL. The DNS lookup is injectable (mirrors this adapter's existing fetchImpl pattern) so tests are hermetic. FabricOneLakeAdapter.getPool() now calls the guard before loadDriver()/ getToken()/opening the TDS pool, so a blocked target never reaches a real outbound connection attempt or spends an AAD token exchange. Tests: new tests/p0/fabric-onelake-ssrf-guard.test.ts unit-tests the guard module directly (range boundaries, IPv4-mapped-IPv6 bypass attempt, fail-closed on DNS failure/empty answer). New adapter-level tests in tests/p0/fabric-onelake-adapter.test.ts prove (a) a private-IP-resolving sqlEndpoint is rejected before fetch/connect is ever called, (b) a literal loopback sqlEndpoint is rejected the same way, and (c) a normal external Fabric hostname still passes the guard and completes the query — the guard doesn't false-block legitimate targets. Existing adapter tests are updated to inject a deterministic DNS resolver so they stay hermetic instead of depending on real DNS. Full suite: 997 passed, 0 failed, 184 skipped (self-skipping realinfra tests with no live backend this run). typecheck and lint clean on all touched files. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-11 02:18:23 +02:00
adminandClaude Opus 5	db868f4bdf	fix(prod): close legacy storage fallbacks in orders/subscriptions/blobs ... The `resolveStoreMode` kill switch (Master-DoD §3/§10) covered the newer `src/repositories/*` stores but not two older paths, both of which are live production execution paths today. 1. LEGACY NEXT.JS STORES. `lib/orders-store.ts` and `lib/subscriptions-store.ts` predate `src/platform/dependency-mode.ts` and called `getSql()` directly, silently falling back to module-global `Map`s when no database is configured. For orders, payments and subscriptions that is not a degraded mode, it is invisible loss of money-bearing state: the API returns 201 and the row evaporates on the next restart or on any other replica. The live 0pt deployment (Coolify app 54) runs NODE_ENV=production with DATABASE_URL, POSTGRES_URL and POSTGRES_PRISMA_URL all unset — so this is the behavior in production right now, across 7 API routes. These now go through `getSqlForDurableStore()`, which reuses the SAME `resolveStoreMode` decision every `src/repositories/*` store already uses rather than re-implementing a second production check. The reuse is load-bearing: `isProductionRuntime` deliberately exempts `NEXT_PHASE=phase-production-build`, because `next build` runs page-data collection under NODE_ENV=production while serving nothing. A naive `process.env.NODE_ENV === "production"` test here would have failed the BUILD instead of protecting a request path. 2. LOCALBLOBSTORE. It writes document bytes to a container-local disk while `document-capture-service` registers an artifact pointer claiming the bytes are stored — durable object storage silently swapped for ephemeral disk. It is the default blob store for both the capture and extraction services. In production it now raises DEPENDENCY_UNAVAILABLE (capability blocked: no ST0RE bytes path exists yet) instead of fabricating success. Asserted per-operation, not in the constructor, so merely wiring the services is not fatal — only actually persisting or reading bytes is. Evidence: full suite 956 passed / 184 skipped, typecheck clean, dependency-cruiser 0 errors, lint identical to main's pre-existing baseline (17 problems, none in changed files). Both guards asserted in both directions and mutation-tested: bypassing resolveStoreMode -> 2 failed; dropping the write assert -> 2 failed; dropping the read assert -> 1 failed; all restored -> 8 passed. 7 non-test call sites. DEPLOYMENT NOTE: merging changes no runtime (no Gitea webhook exists on any repo; deploys are manual). Deploying this build REQUIRES provisioning DATABASE_URL for 0pt first, or the order/subscription routes will correctly return DEPENDENCY_UNAVAILABLE instead of silently accepting orders into memory. That provisioning is a Simon action. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-09 17:38:51 +02:00
adminandClaude Opus 4.8	e6d3101501	fix: 17 confirmed bugs from full-repo audit (edge + Python engine) (#5) ... * docs: correct stale quality-check-service.ts comment references Two source comments still cited src/services/quality-check-service.ts as an existing precedent. It doesn't exist anywhere in this repo's history (git log --all: zero commits, any branch, ever) -- confirmed during the earlier full-doc-corpus accuracy pass. Points each comment at the real precedent instead (document-extraction-service.ts / iceberg-write-service.ts). Applied from task_05ec36aa, spun off during that pass. * fix: 17 confirmed bugs from full-repo audit (edge + Python engine) Found by an 8-finder bug hunt across app/api, src/services, src/clients, frontend, the Python engine, the data layer, config/infra, and tests, then independently adversarially verified per finding (32 raw findings -> 27 confirmed real bugs; 5 refuted). This commit applies the 17 confirmed as safe, mechanical fixes -- no architecture/design decision required. The other 10 need a decision and are reported separately, not touched here. Most consequential, app/api/payments/[order_id]/deposit/route.ts: the client-supplied Origin request header was trusted unsanitized both as a server-side fetch target (SSRF) and as Stripe Checkout success/cancel redirect URLs (open redirect tied to a real payment flow), and a failed order lookup silently fell through to a hardcoded deposit amount instead of 404. Fixed by reading the order directly via lib/orders-store.ts (mirroring the sibling release/route.ts, which already did this correctly) instead of both trusting the Origin header and self-issuing an HTTP fetch. Also fixed: - 5 routes (orders, orders/[id], estimates, subscriptions, ai/parse) that 500'd instead of 400ing on a literal JSON `null` body, since req.json() resolves (not rejects) for that input and bypasses the try/catch guard. - app/api/0pt/lakehouse/mappings/{,[mappingId]/{,writes/}}route.ts each instantiated their own private service instances, so a mapping created via POST was invisible to the sibling GET and writes routes even before the separately-tracked dataset-registration gap. Extracted a shared singleton module, src/services/lakehouse-mapping-registry.ts. - app/api/0pt/documents/[documentId]/extraction/route.ts collapsed every error (not-configured, policy-denied, policy-approval-required, not-found) into a blanket 400; now status-mapped like the sibling sources/[sourceId]/query route. - app/api/vehicles/route.ts: plate query param wasn't URL-encoded before being concatenated into the outbound RDW request, allowing extra query parameters to be injected; added a strict allowlist + encodeURIComponent. - app/api/uploads/route.ts: POST returned a fake 200 success with put_url: null even when "configured", instead of continuing to report 501 until presign generation is actually implemented. - src/adapters/document-intelligence-adapter.ts: the result-polling loop never checked response.ok, so a non-2xx poll response (auth expiry, 429, 5xx) was silently retried until a generic timeout masked the real error. - app/order/[id]/page.tsx: finish() never cleared the production-simulation setInterval, so it kept firing (and re-rendering) forever after delivery. - app/admin/page.tsx: the metrics fetch had no response/shape validation (unlike the adjacent orders fetch), rendering literal "undefined" stat tiles on a malformed response instead of falling back to <ErrorState/>. - services/api/workers/pipeline.py: `config.get("seeds") or DEMO_SEEDS` used truthy-or, so an explicit empty seeds dict was silently replaced with hardcoded demo org numbers instead of being respected as empty. - services/api/workers/resolve.py: corroboration (confidence/agreed_sources bump) no longer fires for two hits from the same source under fuzzy match -- only a genuinely independent source now counts, per docs/06's own ">=2 independent sources agree" definition -- and a merged record's provenance array now actually includes the corroborating source's fields instead of only a bare source-name string. - services/api/orchestrator/main.py: create_order's int(...) on unvalidated client volume/confidence fields raised on any decimal-formatted input (int("92.5") -> ValueError); now coerced via float() first with a safe default. /vehicles/{plate} and /screen also now catch connector exceptions and degrade gracefully, matching pipeline.py's existing pattern for the same connectors. - lib/orders-store.ts: postgres.js (pinned v3.4.9) returns bigint/numeric columns as strings by default; getOrder/listOrders/setStatus were silently handing callers stringified money fields. Added a narrow per-row coercion instead of touching the shared client's global type map (which would affect unrelated tables' bigint/numeric columns too). - lib/subscriptions-store.ts: the in-memory fallback returned oldest-first while the Postgres branch explicitly orders newest-first; now consistent, mirroring the identical fix already in orders-store.ts. - app/api/auth/login/route.ts: DEV_LOGIN_KEY was compared with a plain !==, a non-constant-time comparison; replaced with crypto.timingSafeEqual. Verified before commit: tsc --noEmit clean; vitest run 88 passed, 1 todo, 0 failures (13 files, unchanged from before this commit -- no existing test's assertions needed to change). services/api/workers/resolve.py's source-novelty and provenance-merge logic additionally verified by direct execution against synthetic same-source/cross-source inputs (no Python test suite exists in this repo to add to). services/api/workers/pipeline.py and services/api/orchestrator/main.py verified with python -m py_compile (no httpx/fastapi installed in this environment to run them directly). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix(engine): treat explicit seeds:null as missing to avoid 500 in run_job Four-eyes follow-up to this PR's own seeds change. Switching from `config.get('seeds') or DEMO_SEEDS` to `config['seeds'] if 'seeds' in config` correctly stopped an explicit empty {} from being backfilled with DEMO_SEEDS, but regressed on client-controlled `{"seeds": null}`: seeds became None and the downstream `seeds.get(market, [])` raised AttributeError -> 500. That path is reachable (POST /orders stores raw body.config; POST /orders/{id}/run passes it straight to run_job). Using `config.get('seeds') is not None` keeps the intended behaviour (explicit {} honoured, never silently seeded with demo data) while restoring the None-tolerance the old idiom had. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> --------- Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-22 18:52:19 +02:00
adminandClaude Sonnet 5	c89731115c	feat: add 0pt.query_source, 0pt.document_ocr, 0pt.write_external_record capabilities ... Three new, tenant-agnostic P0 capabilities: - 0pt.query_source: bounded, timeout/row-capped ad-hoc SQL query execution against registered database sources, via a Fabric/OneLake adapter (Azure AD credential-based mssql connection), with AUD0 audit events and an app/api/0pt/sources/[sourceId]/query endpoint. - 0pt.document_ocr (document capture + extraction): mailbox-based document intake via Microsoft Graph, OCR/field extraction via Azure Document Intelligence, with capture/extraction API endpoints and services that never fabricate extracted values. - 0pt.write_external_record (external writeback): a generic writeback-adapter contract plus a concrete Odoo bills adapter that matches partners via Fabric, backing an external-writeback-service for pushing records to downstream systems of record. Known interim gaps: - src/adapters/local-blob-store.ts is an interim ST0RE substitute pending the real ST0RE artifact-store integration. - mssql is used by the Fabric/OneLake adapter but deliberately not yet added to package.json (pending `pnpm add mssql` once the concurrent session's package.json/dependency changes settle). A separate, concurrently-active session has unrelated in-flight changes in this same working tree (data-platform catalog/lineage/feature-store, dataset quality, lakehouse/Iceberg docs, deploy scaffolding, package.json/ pnpm-lock.yaml updates, etc.) — none of that is touched or included here. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-08 19:32:43 +02:00