skypress/src/lib/auth/ at 49f0a1507ee672e9ba95d0dbfcdc489dfc433e3b · jeremy.herve.bzh/skypress · Tangled

jeremy.herve.bzh / skypress

0

A calm place to write long-form, and publish it to the open social web. skypress.blog/

0

skypress / src / lib / auth /

at 49f0a1507ee672e9ba95d0dbfcdc489dfc433e3b 12 files

Jeremy Herve Cover mention handle fallback + tighten profile regex 14d ago

AuthProvider.tsx

Add appBarNav helper for the shared top bar

2 weeks ago

Refine landing: grotesk buttons, stronger hero contrast, honest copy - Buttons use Overused Grotesk instead of IBM Plex Mono (labels stay mono) - Hero lede/actions: higher text opacity, text-shadow, frosted ghost chips so they read at every phase - Drop the inaccurate 'your own server' claim (most users are on Bluesky's PDS) -> 'your account' / 'the open social web' - 'built on Gutenberg' -> 'built with the WordPress block editor'

2 weeks ago

Harden read path: validate author handle before resolver fetch The public renderer took the `@author` segment straight from the URL and used it as a fetch host, so a non-handle-shaped value (e.g. `evil.com/.well-known/atproto-did`, `evil.com:8080`, `evil.com?x=y`) could smuggle a path/port/query into the outbound request and turn the worker into a GET request proxy to arbitrary public hosts. - Add `isValidHandleOrDid()` to auth/config: accepts only a syntactic handle or DID, rejecting URLs and anything with a path, port, query or scheme (stricter than `isValidAccountInput`). - Gate `resolveHandleToDid()` on it before any network call, so both reader pages reject bad input (they already 404 on null). `safeFetch` stays the internal-host backstop; this is the syntactic gate in front. - Regression test asserts malicious input resolves to null with zero fetches; DIDs pass through without a network call. Also sanitise preview.astro's `set:html` (static input today) so every raw-HTML sink uniformly goes through `sanitizeArticleHtml`.

2 weeks ago

Harden read path: validate author handle before resolver fetch The public renderer took the `@author` segment straight from the URL and used it as a fetch host, so a non-handle-shaped value (e.g. `evil.com/.well-known/atproto-did`, `evil.com:8080`, `evil.com?x=y`) could smuggle a path/port/query into the outbound request and turn the worker into a GET request proxy to arbitrary public hosts. - Add `isValidHandleOrDid()` to auth/config: accepts only a syntactic handle or DID, rejecting URLs and anything with a path, port, query or scheme (stricter than `isValidAccountInput`). - Gate `resolveHandleToDid()` on it before any network call, so both reader pages reject bad input (they already 404 on null). `safeFetch` stays the internal-host backstop; this is the syntactic gate in front. - Regression test asserts malicious input resolves to null with zero fetches; DIDs pass through without a network call. Also sanitise preview.astro's `set:html` (static input today) so every raw-HTML sink uniformly goes through `sanitizeArticleHtml`.

2 weeks ago

Add owner-only "Create your first publication" CTA on the empty author page When a signed-in writer views their own public author page and has no publications yet, surface a button linking to /dashboard instead of only the "No SkyPress publications yet." line. The button is gated to the profile owner (viewer DID === profile DID); logged-out visitors and other accounts see the unchanged static text. The author page is server-rendered and cannot import the auth stack, so owner detection runs in a client:only React island (CreatePublicationCta) wrapping the existing @wordpress-free AuthProvider. The DID-comparison decision lives in a pure isProfileOwner helper, unit-tested per the repo's pure-logic test convention; its CSS sits in a global block since the island's DOM is outside Astro's scoped styles.

2 weeks ago

Add owner-only "Create your first publication" CTA on the empty author page When a signed-in writer views their own public author page and has no publications yet, surface a button linking to /dashboard instead of only the "No SkyPress publications yet." line. The button is gated to the profile owner (viewer DID === profile DID); logged-out visitors and other accounts see the unchanged static text. The author page is server-rendered and cannot import the auth stack, so owner detection runs in a client:only React island (CreatePublicationCta) wrapping the existing @wordpress-free AuthProvider. The DID-comparison decision lives in a pure isProfileOwner helper, unit-tested per the repo's pure-logic test convention; its CSS sits in a global block since the island's DOM is outside Astro's scoped styles.

2 weeks ago

Add appBarNav helper for the shared top bar

2 weeks ago

Add appBarNav helper for the shared top bar

2 weeks ago

Add SP2 lexicon + two-record publish Define and document the SkyPress content lexicon and implement the core publish mechanic: write the writer's article to their PDS as a site.standard.document (block tree in content + de-facto-required textContent), ensure their site.standard.publication exists, and post a companion app.bsky.feed.post linking to the public article (POSSE). - lexicons/: blog.skypress.content.gutenberg.json + a README documenting every record SkyPress writes (verified site.standard.* shapes, ours, app.bsky). - src/lib/publish/records.ts: pure record/URL/slug builders + normalizeBlocks (strips clientId, JSON-normalises rich-text) — unit-tested. - src/lib/publish/publisher.ts: ensurePublication (matches OUR publication by url, so we never attach to another tool's standard.site publication) -> create post -> create document with bskyPostRef. Order avoids a circular dependency. - PublishPanel: title + publish with an unmistakable "this also posts to Bluesky" confirmation (brief §10). - Dev loopback client now requests `atproto transition:generic` so createRecord is authorized (one re-auth; handle now resolves via appview). Verified end-to-end against a real account: records fetched back from the PDS confirm the block tree stored as clean JSON, correct textContent, a real Bluesky post with an external embed, and bskyPostRef. The live test caught a bug (reusing a foreign publication) which is fixed by matching on url.

2 weeks ago

profile.test.ts

Add accountMenuItems helper for the masthead menu

2 weeks ago

Add accountMenuItems helper for the masthead menu

2 weeks ago

Add SP1 atproto OAuth (login, session, the Agent) Gate the editor behind atproto OAuth using a browser public client (@atproto/oauth-client-browser), per Decision 0004 — chosen over the brief's named @atproto/oauth-client-node because a confidential client needs a server-side session store, which would reintroduce the database the no-DB/edge architecture avoids. A public client (PKCE/DPoP, tokens in IndexedDB) needs no backend; "secrets never in the client" holds trivially (no secret). Flow: client.init() once on load (restore session or process the redirect callback) -> signIn(handle) redirects to the user's auth server -> session -> new Agent(session) for later com.atproto.repo.* calls (SP2). - Pure config/handle/scope logic in src/lib/auth/config.ts (7 Vitest tests). - AuthProvider context + useAuth + LoginForm; Studio island gates SkyEditor. - Dev uses an atproto loopback client; the client_id must be path-less and the origin must be 127.0.0.1 (not localhost) — oauth.ts builds it explicitly. - public/client-metadata.json for the hosted (prod) client (origin finalized in SP7). Verified end-to-end against a real Bluesky account: redirect to the genuine bsky.social authorize page, callback exchange, signed-in editor, and session persistence across reload. SP1 scope is atproto + transition:generic at the metadata level; granular write scopes land in SP2.

2 weeks ago