fix(pdf): let PdfService reach the export route past auth middleware #127

Merged

shad0w merged 1 commit from fix/pdf-export-middleware into master

2026-06-24 09:27:36 +00:00

shad0w commented

2026-06-24 09:26:03 +00:00

Owner

Fixes the blocker found while enabling the PDF microservice on pms1: even with PDF_SERVICE_URL + PDF_SERVICE_TOKEN set and the service healthy, "Email PO to vendor" could never render a real PDF.

Root cause

PdfService fetches /api/po/<id>/export?...&svc=<token> without a user session, authenticating with a svc token equal to PDF_SERVICE_TOKEN. The route handler validates that token — but middleware.ts runs first, and its matcher doesn't exempt the export route, so every unauthenticated fetch is redirected to /login (307) and the svc bypass never runs. Confirmed on pms1: the export route returned 307 for the correct token on both the local and public host.

Fix

Middleware now lets only /api/po/<id>/export through when its svc param matches process.env.PDF_SERVICE_TOKEN; everything else stays auth-gated, and the route handler still re-validates the token (defense in depth). The matching logic is a dependency-free, edge-safe, unit-tested helper (lib/pdf-export-auth.ts). Middleware already reads server env at runtime via auth() (NEXTAUTH_SECRET), so reading PDF_SERVICE_TOKEN there is consistent.

Verification (running build, local dev)

correct svc + real PO → 200
correct svc + bogus PO → 404 (handler ran, not redirected)
wrong / missing svc → 307 (still gated)
tsc clean; 324 unit tests green (+3 for the helper)

Deploy note

The pms1 env is already configured (PDF_SERVICE_URL, PDF_SERVICE_TOKEN, APP_INTERNAL_URL=http://localhost:3000) and pdf-service is live on :3005 with the matching token. Once this merges and a release tag deploys, "Email to vendor" should work end-to-end on prod.

🤖 Generated with Claude Code

Fixes the blocker found while enabling the PDF microservice on pms1: even with `PDF_SERVICE_URL` + `PDF_SERVICE_TOKEN` set and the service healthy, **"Email PO to vendor" could never render a real PDF**. ## Root cause PdfService fetches `/api/po/<id>/export?...&svc=<token>` **without a user session**, authenticating with a `svc` token equal to `PDF_SERVICE_TOKEN`. The route handler validates that token — but `middleware.ts` runs first, and its matcher doesn't exempt the export route, so every unauthenticated fetch is redirected to `/login` (**307**) and the `svc` bypass never runs. Confirmed on pms1: the export route returned 307 for the correct token on both the local and public host. ## Fix Middleware now lets **only** `/api/po/<id>/export` through when its `svc` param matches `process.env.PDF_SERVICE_TOKEN`; everything else stays auth-gated, and the route handler still re-validates the token (defense in depth). The matching logic is a dependency-free, edge-safe, unit-tested helper (`lib/pdf-export-auth.ts`). Middleware already reads server env at runtime via `auth()` (`NEXTAUTH_SECRET`), so reading `PDF_SERVICE_TOKEN` there is consistent. ## Verification (running build, local dev) - correct `svc` + real PO → **200** - correct `svc` + bogus PO → **404** (handler ran, not redirected) - wrong / missing `svc` → **307** (still gated) - `tsc` clean; **324** unit tests green (+3 for the helper) ## Deploy note The pms1 env is already configured (`PDF_SERVICE_URL`, `PDF_SERVICE_TOKEN`, `APP_INTERNAL_URL=http://localhost:3000`) and pdf-service is live on :3005 with the matching token. Once this merges and a release tag deploys, "Email to vendor" should work end-to-end on prod. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

shad0w added 1 commit 2026-06-24 09:26:03 +00:00

fix(pdf): let PdfService reach the PO export route past auth middleware

PR checks / checks (pull_request) Successful in 49s

Details

PR checks / integration (pull_request) Successful in 31s

Details

d1af1e6b12

"Email PO to vendor" (issue #14) relies on PdfService fetching
/api/po/<id>/export?...&svc=<token> WITHOUT a user session, authenticating
with a `svc` token that matches PDF_SERVICE_TOKEN. The route handler validates
that token, but the auth middleware runs first and its matcher doesn't exempt
the export route — so every unauthenticated fetch was redirected to /login
(307) and the svc bypass never executed. Net effect: the feature could never
render a real PDF on any deployed env, even with the service configured.

Fix: middleware now lets exactly `/api/po/<id>/export` through when its `svc`
query param matches `process.env.PDF_SERVICE_TOKEN` (the route handler still
re-validates it — defense in depth). Everything else stays auth-gated. The
match lives in a dependency-free, edge-safe, unit-tested helper
(lib/pdf-export-auth.ts); middleware already reads server env at runtime via
auth()/NEXTAUTH_SECRET, so reading PDF_SERVICE_TOKEN there is consistent.

Verified on a running build: correct svc + real PO -> 200, correct svc + bogus
PO -> 404 (handler ran), wrong/no svc -> 307 (still gated). 324 unit tests
green; tsc clean.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>