fix: add /embed/ and /.well-known/ to self-hosting proxy whitelist

[shashank-sn]

Summary

Adds /embed/ and /.well-known/ paths to the self-hosting proxy whitelist in apps/web/proxy.ts.

On self-hosted deployments (when NEXT_PUBLIC_IS_CAP !== "true"), the proxy middleware redirects all unwhitelisted paths to /login. Two important routes were missing:

1. /embed/<videoId> — breaks iframe embeds on self-hosted instances. The share page works correctly because /s/ is already whitelisted; /embed/ was overlooked. This was fully root-caused by the community in /embed/* routes redirect to /login on self-hosted, breaking iframe embeds #1768.

2. /.well-known/workflow/v1/* — blocks the workflow/queue dispatch used by transcription, AI summaries, and video processing. The Turbopack standalone build returns the SPA HTML shell instead of routing to the handlers. Root-caused in /.well-known/workflow/v1/* routes blocked by proxy whitelist on self-hosted #1774 and Self-hosted video processing silently broken: .well-known/workflow/v1/* route handlers return the SPA HTML shell (Turbopack standalone build) #1944.

Fix

Two lines added to the existing whitelist pattern:

 path.startsWith("/verify-otp") ||
+path.startsWith("/embed/") ||
+path.startsWith("/.well-known/")

Verification

• The /.well-known/ path is reserved by RFC 8615 for well-known URIs — a sensible whitelist entry for workflow routes, ATproto verification, etc.
• Both fixes are identical in shape to existing whitelist entries
• Verified by community members in /.well-known/workflow/v1/* routes blocked by proxy whitelist on self-hosted #1774 and /embed/* routes redirect to /login on self-hosted, breaking iframe embeds #1768 via curl/private-browser testing

Fixes #1768, #1774, #1944, #906

Greptile Summary

This PR expands the self-hosted proxy allowlist for public routes. The main changes are:

• /embed/ requests can reach embed pages instead of /login.
• /.well-known/ requests can reach well-known and workflow routes.
• The change is limited to apps/web/proxy.ts.

Confidence Score: 4/5

The /.well-known/ allowlist entry should be tightened before merging.

• /embed/ appears to route through existing video visibility checks.
• /.well-known/ is broader than the known workflow and static well-known paths.
• Any unprotected handler under that namespace can now be reached without the proxy login gate.

apps/web/proxy.ts

Security Review

The broad /.well-known/ prefix creates a security-boundary risk for any handler under that namespace that does not enforce its own auth or signature checks.

Important Files Changed

Filename	Overview
apps/web/proxy.ts	Adds /embed/ and /.well-known/ to the self-hosted proxy allowlist; the broad well-known prefix should be narrowed or paired with route-level protection.

Prompt To Fix All With AI

Fix the following 2 code review issues. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 2
apps/web/proxy.ts:60
**Broad Well-Known Whitelist**

When self-hosted production traffic reaches any dynamic route under `/.well-known/`, this prefix lets it bypass the proxy login gate. The inspected app has workflow routing configured under this namespace, so if any current or later handler there lacks its own auth or signature check, unauthenticated callers can reach processing endpoints that were previously blocked by the proxy.

### Issue 2 of 2
apps/web/proxy.ts:58-60
**Whitelist Indentation Drift**

These two entries are indented differently from the surrounding `path.startsWith(...)` clauses. The repo’s TS formatting rules require tab-aligned indentation, so this hunk can be reformatted or flagged by the formatter.

```suggestion
				path.startsWith("/verify-otp") ||
				path.startsWith("/embed/") ||
				path.startsWith("/.well-known/")
```

_{Reviews (1): Last reviewed commit: "fix: add /embed/ and /.well-known/ to se..." | Re-trigger Greptile}

Greptile also left 2 inline comments on this PR.

Context used:

• Context used - CLAUDE.md (source)
• Context used - AGENTS.md (source)

[greptile-apps]

Broad Well-Known Whitelist

When self-hosted production traffic reaches any dynamic route under /.well-known/, this prefix lets it bypass the proxy login gate. The inspected app has workflow routing configured under this namespace, so if any current or later handler there lacks its own auth or signature check, unauthenticated callers can reach processing endpoints that were previously blocked by the proxy.

Prompt To Fix With AI

This is a comment left during a code review.
Path: apps/web/proxy.ts
Line: 60

Comment:
**Broad Well-Known Whitelist**

When self-hosted production traffic reaches any dynamic route under `/.well-known/`, this prefix lets it bypass the proxy login gate. The inspected app has workflow routing configured under this namespace, so if any current or later handler there lacks its own auth or signature check, unauthenticated callers can reach processing endpoints that were previously blocked by the proxy.

How can I resolve this? If you propose a fix, please make it concise.

[shashank-sn]

Addressed the well-known review comment — narrowed from /.well-known/ to /.well-known/workflow/ so only the workflow queue prefix bypasses the proxy gate, not the entire well-known namespace.

[shashank-sn]

All comments addressed:

• Well-known whitelist narrowed: Changed from /.well-known/ to /.well-known/workflow/ — only the workflow prefix bypasses the proxy gate now.
• Indentation drift: Fixed in 795b614 — entries now tab-aligned with surrounding path.startsWith() calls.
• Trailing slash: Intentional — /embed (without slash) and /.well-known (without slash) are non-functional paths. Only sub-routes need bypass.