Changeset 04d5aeb in Klonkt for src/routes

Timestamp:

08/02/2026 09:42:34 PM (5 weeks ago)

Author:

Robin <roboburr@…>

Branches:

main

Children:

5327324

Parents:

f3a58a4

Message:

Replies op friends-only posts: de deur die nooit open kon

De hangende reply-klacht (Robins schermafdruk, 2-8: 502
cannot_resolve_inReplyTo) bleek een keten van drie schakels. Een
friends-post slaat fan_only = 1 op. De /ap/notes-route verborg elke
fan_only post voor IEDEREEN, zonder ooit naar de Signature-header te
kijken. En resolveRemoteNote haalde zelfs de eigen notes over publiek
HTTPS op. De gesigneerde resolutie die het reply-pad sinds 30-7 doet
klopte dus aan bij een deur die niet open kon: elke reply op een
friends-only post (Shaers standaard!) stierf voor de aflevering.
Publieke posts deden het wel, vandaar dat het grillig leek.

Twee reparaties. EEN: een note die hier woont verlaat het pand niet
meer. resolveRemoteNote bouwt hem uit de database (localNoteObject,
localActorObject, ook in de thread-klim), waarbij de eigen host in
ASCII vergeleken wordt: xn--zz9h.example IS het hart-domein, Barts
WebFinger-les van vanochtend, nu ook op het reply-pad en in
postIdFromNoteUrl. Niet-publieke notes alleen voor de eigen C2S-caller
(forSlug); een hairpin-fetch die op een thuisserver achter een tunnel
faalt is er niet meer.

TWEE: authorized fetch op GET /ap/notes/:id. Een geverifieerde follower
verdient de friends-only Note (noteAudience/mayReadNote); een vreemde
krijgt exact dezelfde 404 als vroeger, een geblokkeerde actor ook (de
staande regel: gesigneerde fetch van een geblokkeerde verdient de lege
verzameling, domein-blocks incluis) en direct wordt nooit over GET
geserveerd.

Changed files:
src/services/ActivityPubService.js

• asciiOrigin/isOwnUrl: hostvergelijking via WHATWG URL, geen bytes
• postIdFromNoteUrl: ASCII-origins in plaats van startsWith
• localNoteObject/localActorObject: eigen notes en actors uit de DB
• resolveRemoteNote: kortsluiting op alle drie de fetch-punten
• noteAudience/mayReadNote: de leespoort, ook in de default-export

src/routes/activitypub.js

• /ap/notes/:id: fan_only niet meer in de SELECT maar achter de poort; verifyRequest beslist, try eromheen (Express 4 vangt een async rejection niet: een fout werd een eeuwig hangende request, precies zo gevonden tijdens het bouwen)

New file:
test/reply-friends-only.test.js

• reply op eigen friends-post resolvet lokaal (geen server achter het testdomein: HTTP zou 502 geven) en threadt onder de post
• unicode- en punycode-spelling zijn een host
• onbestaande note blijft luid 502
• mayReadNote-matrix: follower/vreemde/blocked/domein-block/direct
• route: vreemde 404, garbage-signature 404, direct 404, publiek 200

remarks: de suite staat op 384. Wat dit NIET oplost: een reply waarvan
de parent op een derde server staat die zelf geen authorized fetch
doet; dat is de andere kant van dezelfde deur en die is van hen.

-robo
Co-Authored-By: Claude Opus 4.8 <noreply@…>

File:

• src/routes/activitypub.js (modified) (1 diff)

src/routes/activitypub.js

@@ -585 +585 @@
 
 // ── Note ──────────────────────────────────────────────────────────
-router.get('/ap/notes/:id', (req, res) => {
+router.get('/ap/notes/:id', async (req, res) => {
+  // No fan_only filter in the SELECT anymore: a friends-only post is not
+  // absent, it is GATED. The old route hid it from EVERYONE, also from the
+  // follower whose friendship earns it — so the signed resolution the reply
+  // path performs knocked on a door that could never open, and every reply
+  // to a friends-only post (Shaer's default!) died in
+  // cannot_resolve_inReplyTo. Strangers still get the exact same 404, so a
+  // note's existence stays as private as before.
   const post = db.prepare(
-    "SELECT * FROM posts WHERE id = ? AND status = 'published' AND (fan_only IS NULL OR fan_only = 0)"
+    "SELECT * FROM posts WHERE id = ? AND status = 'published'"
   ).get(req.params.id);
+  if (post && AP.noteAudience(post) !== 'public') {
+    // The whole gate in a try: this is the only async route in this file,
+    // and Express 4 does not catch an async rejection — the request would
+    // hang forever instead of failing (which is exactly how the missing
+    // default-export entry manifested while building this). Any error here
+    // reads as "not authorized", never as silence.
+    try {
+      if (AP.noteAudience(post) === 'direct') return res.status(404).end();
+      const gsite = db.prepare('SELECT * FROM sites WHERE id = ?').get(post.site_id);
+      const actor = await AP.verifyRequest(req).catch(() => null);
+      if (!actor || !AP.mayReadNote(gsite, post, actor.id)) return res.status(404).end();
+    } catch { return res.status(404).end(); }
+  }
   if (!post) {
     // Could be one of OUR outbound replies (ap_outbox), not a post.