CHORE: Prepare hosted operations and remote development - #39
Conversation
|
Warning Review limit reached
On-demand reviews are free for the next 9 days. After that, they cost $0.25 per reviewed file. Or wait 33 minutes for your next included review. View limit detailsLimit details: You’ve used all 6 included reviews currently available. Your 49 included PR review attempts over the past 7 days set your current allowance at 6 reviews per hour. Review configuration: ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Team Run ID: 📒 Files selected for processing (26)
Comment |
![macroscopeapp[bot]](https://avatars.githubusercontent.com/in/900172?s=60&v=4){kind=small}
| - Hotlink protection off (public file links are the product). | ||
| - Universal SSL with the wildcard, so `*.<content domain>` is covered | ||
| when per-tenant hostnames land. | ||
| - Notifications: the two alerts in `docs/observability.md` (DLQ depth, |
There was a problem hiding this comment.
🟡 Medium docs/launch-checklist.md:33
The launch gate cannot configure or verify the required DLQ-depth and 5xx-rate alerts because it points operators to docs/observability.md, which is absent from the repository. Add that document with the alert thresholds and destinations, or update the checklist to reference the document that contains them.
🚀 Reply "fix it for me" or copy this AI Prompt for your agent:
In file @docs/launch-checklist.md around line 33:
The launch gate cannot configure or verify the required DLQ-depth and 5xx-rate alerts because it points operators to `docs/observability.md`, which is absent from the repository. Add that document with the alert thresholds and destinations, or update the checklist to reference the document that contains them.
| server: { | ||
| // The dev server binds 0.0.0.0 so other devices can reach it; allow | ||
| // any hostname since the app's own host gate enforces the origins. | ||
| allowedHosts: true |
There was a problem hiding this comment.
🟠 High web/vite.config.ts:12
server.allowedHosts: true disables Vite's host allowlist, so a DNS-rebound hostname can reach the 0.0.0.0 dev server and retrieve source/content before SvelteKit's host-gate runs. Replace this with an explicit allowlist of the development hostnames (or remove the override to use Vite's defaults).
🚀 Reply "fix it for me" or copy this AI Prompt for your agent:
In file @apps/web/vite.config.ts around line 12:
`server.allowedHosts: true` disables Vite's host allowlist, so a DNS-rebound hostname can reach the `0.0.0.0` dev server and retrieve source/content before SvelteKit's `host-gate` runs. Replace this with an explicit allowlist of the development hostnames (or remove the override to use Vite's defaults).
| names.session, | ||
| resolved.refreshedSession, | ||
| sessionCookieOptions | ||
| sessionCookieOptions(names.secure) |
There was a problem hiding this comment.
🔴 Critical src/hooks.server.ts:74
For an HTTP DASHBOARD_ORIGIN, the refresh path sets the authenticated session without the Secure attribute, so browsers transmit the bearer cookie over cleartext on every subsequent request. HttpOnly and SameSite do not prevent network interception or replay; enforce HTTPS for the dashboard origin and reject HTTP rather than issuing this session cookie.
🚀 Reply "fix it for me" or copy this AI Prompt for your agent:
In file @apps/web/src/hooks.server.ts around line 74:
For an HTTP `DASHBOARD_ORIGIN`, the refresh path sets the authenticated session without the `Secure` attribute, so browsers transmit the bearer cookie over cleartext on every subsequent request. `HttpOnly` and `SameSite` do not prevent network interception or replay; enforce HTTPS for the dashboard origin and reject HTTP rather than issuing this session cookie.
3804f74 to
d301e21
Compare
PlanetScale's automatic backups are the primary copy, the home-host pg_dump the independent one, and R2 gets object versioning or a second bucket. The backup host installer now checks for pg_dump beside rclone. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Public pages, abuse and DMCA contacts, content-zone settings, the secrets that must exist before the first deploy, and the verification skill as the final gate. release.md links to it from first-time setup and the README intro now describes the hosted direction while keeping the self-hosting instructions. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Browsers refuse Secure cookies on http origins other than localhost, so signing in from a LAN or Tailscale hostname in development silently lost the session. The cookie names and Secure flag now follow the dashboard origin's scheme. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
d71d8e9 to
5746003
Compare
1 participant
Fix authentication on remote HTTP development origins and align operations with the hosted stack. Cookies use origin-appropriate names and deletion options, device approval survives sign-in, and Vite accepts only explicitly allowed development hosts. Uploads and notifications use secure random ephemeral IDs available on HTTP origins.
Launch, restore, observability, and deployment skills now describe the hosted services. Recovering historical site publications requires a matching earlier database snapshot and retained object bytes; synthetic version markers cannot reconstruct historical paths.
Validation:
Stack layer 10/11: depends on #38; followed by #40. Live WorkOS, DNS/TLS, provider alerts, paid sandbox flows, and restore drills remain launch checks. No merge or deployment.
Note
Make WorkOS session cookies origin-aware and prepare hosted operations docs
DASHBOARD_ORIGINacross sign-in, callback, sign-out, session refresh, and request auth in hooks.server.ts, request-auth.ts, and the auth routescreateClientIdin client-id.ts usingcrypto.getRandomValuesso toast and upload managers work in HTTP contexts whererandomUUIDis unavailable; updates toast.svelte.ts and uploads.svelte.tsDATABASE_URLoverrides, and HTTP-vs-HTTPS cookie behaviorSecureattributes are now derived fromDASHBOARD_ORIGIN; local HTTP development uses non-secure cookie variants while HTTPS origins use secure ones. Reviewers should verify that every environment'sDASHBOARD_ORIGINis set correctly, since a misconfigured origin will cause cookie name mismatches and lost sessions.Macroscope summarized 5746003.
Safe to merge.
Summary
Reviews (2) · Last reviewed commit: "Document the recoverable history of site..."