Kristian WindandClaude Opus 5
dcb71f4c14
Release / Build and publish image (push) Failing after 10m3s
Bedt om som "abonnering af flere kalendere (ics og webcal?)". Det er også den eneste vej for en privat konto: instansens OAuth-klient er Internal, og Google afviser en konto udefra med `org_internal`, uanset hvad der ellers er sat op. **Samme tabeller.** Et abonnement er én kalender med begivenheder i, og det er præcis det, `calendars` og `calendar_events` allerede beskriver — med vinduet, farven, `shown` og hele fejemaskinen omkring sig. En tabel til ville være en anden vej til det samme sted, og to veje til ét sted er to steder at rette den dag noget om begivenheder ændrer sig. Det, der skulle laves om, var identiteten. En OAuth-konto er én pr. person og udbyder — tokenet er identiteten — mens et abonnement er én pr. adresse, og man har flere. `calendar_accounts_once` er derfor delvist nu: det holder for rækkerne uden adresse, og et andet indeks holder adresserne unikke. Delvise indekser er den ene ting, SQLite kan her, som ellers krævede en tabelombygning. **`webcal://` skrives om til `https://`.** Det er ikke en protokol, noget taler — det er en konvention, der får et skrivebord til at give adressen til kalenderprogrammet i stedet for til browseren, og alle udgivere skriver deres links sådan. At afvise den ville være at afvise folk på en teknikalitet. **Adressen gennem `safedial`, begge halvdele.** Afvist hvor den skrives ned, så den, der står med feltet, får svaret med det samme — og igen på den *opslåede* adresse hver gang den hentes, fordi et navn, der blev godkendt ved indtastningen, kan svare 127.0.0.1, når fejemaskinen kører klokken tre om natten. Det er den sætning, `internal/safedial` selv står og advarer om, og den blev skrevet efter et SSRF-fund i morges. **Hentet én gang, før den gemmes.** En adresse, der ikke kan læses, er en tastefejl langt oftere end en server, der tilfældigvis er nede, og at sige det, mens nogen står med feltet, er de to sekunder værd. Et abonnement, der lydløst aldrig fyldes, er den samme tavshed, notifikationerne havde. Læseren er ny i `internal/ics`, som hidtil kun kunne skrive. To ting, den med vilje ikke gør, står skrevet ved den: den udfolder ikke gentagelser, og den opløser ikke tidszoner. Begge dele er større end de ser ud, og begge har ét sted at høre til den dag de skal. En ting, formatet lærte: DTEND er eksklusiv for en heldagsbegivenhed. Gemmes den, som filen skriver den, dækker hver eneste helligdag også dagen efter sig. Én adresse, der fejler, stopper ikke de andre. Et abonnement er en anden persons server, og den ordinære tilstand for en anden persons server er, at den er i orden indtil en morgen hvor den ikke er. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
31 lines
1.6 KiB
SQL
31 lines
1.6 KiB
SQL
-- Abonnement på en kalender, man kun har en adresse til.
|
|
--
|
|
-- Google-vejen er OAuth: én konto pr. person, hvor tokenet er identiteten, og
|
|
-- `calendar_accounts_once` sørgede for netop det — én række pr. (person,
|
|
-- udbyder). Et abonnement er en anden slags ting. Der er intet token og ingen
|
|
-- konto, kun en adresse, og man har flere: helligdage, en fodboldklub, en
|
|
-- fælleskalender fra arbejdet. Det er derfor det blev bedt om som "flere
|
|
-- kalendere".
|
|
--
|
|
-- Samme tabel frem for en ny. Et abonnement er én kalender med begivenheder i, og
|
|
-- det er præcis det, `calendars` og `calendar_events` allerede beskriver — med
|
|
-- vinduet, `shown`, farven og hele fejemaskinen omkring sig. En tabel til ville
|
|
-- være en anden vej til det samme sted, og to veje til ét sted er to steder at
|
|
-- rette den dag noget om begivenheder ændrer sig.
|
|
--
|
|
-- Adressen bliver identiteten, som tokenet er det for Google. To rækker med den
|
|
-- samme adresse for den samme person ville være den samme kalender hentet to
|
|
-- gange, og der er ingen måde at sige hvilken der gælder.
|
|
ALTER TABLE calendar_accounts ADD COLUMN url TEXT NOT NULL DEFAULT '';
|
|
|
|
-- Det gamle indeks holder stadig for OAuth-rækkerne — dem uden adresse — og
|
|
-- slipper abonnementerne fri. Delvise indekser er den ene ting SQLite kan her,
|
|
-- som en tabelombygning ellers skulle til for.
|
|
DROP INDEX calendar_accounts_once;
|
|
|
|
CREATE UNIQUE INDEX calendar_accounts_once
|
|
ON calendar_accounts (user_id, provider) WHERE url = '';
|
|
|
|
CREATE UNIQUE INDEX calendar_subscription_once
|
|
ON calendar_accounts (user_id, url) WHERE url <> '';
|