Changeset fc41e04 in Klonkt for test

Timestamp:

08/11/2026 05:41:49 PM (4 weeks ago)

Author:

Robin <roboburr@…>

Branches:

main

Children:

cb3001e

Parents:

26b1848

Message:

Een slug is een lokale sleutel, geen naam op de draad (Robins vraag, 11-8)

Aanleiding: bij het rechttrekken van de help-handles bleek @${site.slug} als
handle de deur uit te gaan -- zonder host. Robin vroeg door: waar communiceren we
nog op <slug>, want op een AP-oppervlak mag dat niet voorkomen. Dat leverde een
scherpere vondst op dan de handle zelf.

IN DE INBOX WERD EEN SLUG GERADEN UIT EEN VREEMDE URI. slugFromActorUrl knipt de
staart van /ap/users/<x> af en kijkt NIET naar de host. Op drie plekken kwamen de
uri's van de AFZENDER:

handshake-routering uit to en uit de relatie (Offer/Accept/Reject/Undo)
Flag uit de gerapporteerde object-uri's
Follow uit act.object, op de GEDEELDE inbox (per-actor heeft

slugParam en was dus al veilig)

Een activiteit gericht aan ​https://elders.example/ap/users/dev leverde zo de
slug "dev" op, en die bestaat hier. Dan draaide onze dev de afhandeling van iets
dat nooit aan hem geadresseerd was -- een handshake, een rapport tegen zijn naam,
of een volger in zijn lijst.

localSlugOf deed het al goed: het eist dat de uri met onze eigen basis begint EN
dat de site bestaat. Die stond er, alleen niet op deze drie plekken. Nu wel, en
geexporteerd zodat een test hem kan vastleggen.

Vier tests, met de aanval als eerste erin: een vreemde actor met onze padstaart
geeft null, de onze geeft de slug, een niet-bestaande site geeft null, en een pad
dat er alleen op lijkt telt niet.

WAT ER NOG STAAT, en dat is bewust niet in deze commit: routes/activitypub.js
regel 448 en 756 vallen in hun catch terug op @${slug} -- een handle zonder
host. Dat gebeurt alleen als PUBLIC_BASE_URL onparseerbaar is, dus bij een kapotte
installatie, maar het is dezelfde fout: een halve naam op een AP-oppervlak.

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

File:

• test/inbox-vreemde-slug.test.js (added)