Tokendocumentatie terug naar één werkstation-token

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

BEHEER.md

@@ -96,39 +96,48 @@ docker compose -f docker-compose.dev.yml exec -w /app/frontend app npm run lint
 
 ## Tokens
 
-> **De `Vibe`-organisatie staat op public.** Alles wat alleen *leest* heeft
+**Eén token, op het werkstation.** Dat is genoeg omdat de `Vibe`-organisatie op
-> daardoor geen token meer nodig: `git clone`, `docker compose pull` en de
+public staat: alles wat alleen *leest* heeft geen token meer nodig — `git clone`,
-> update-check van de app werken anoniem. Het host-token hieronder is dus
+`docker compose pull` en de update-check van de app werken anoniem. Wat overblijft
-> optioneel geworden. *Schrijven* blijft geauthenticeerd — een publieke
+is schrijven, en dat gebeurt allemaal vanaf deze ene machine.
-> organisatie verandert daar niets aan.
 
-Twee tokens, gesplitst op machine en op read/write. De grens die iets betekent
+| Token | Machine | Scopes | Gebruikt voor |
-ligt tussen werkstation en server, niet tussen push en release: op één machine
+|---|---|---|---|
-kan wie het ene token kan lezen, het andere ook.
+| `vibefinance-workstation` | dit werkstation | `write:package`, `write:repository` | `docker push` (`release.ps1`, `dev.ps1 push`) én het aanmaken van de Gitea-release |
 
-| Token | Machine | Scopes | Gebruikt voor | Nog nodig? |
+Er is geen apart host-token en geen apart registry-token:
-|---|---|---|---|---|
-| `vibefinance-workstation` | dit werkstation | `write:package`, `write:repository` | `docker push` (`release.ps1`, `dev.ps1 push`) en het aanmaken van de Gitea-release | **Ja** |
-| `vibefinance-host` | de Docker-host | `read:package`, `read:repository` | `docker compose pull` en de update-check van de app | Nee, zolang de organisatie public is |
 
-Aanmaken: Gitea → Settings → Applications → Generate New Token. Doe dat onder een
+- **`git push`** gaat over SSH (`gitea@…:Vibe/VibeFinance.git`), dus die gebruikt
-account dat lid is van de `Vibe`-organisatie: voor schrijven volstaat
+  je SSH-sleutel en niet dit token.
-organisatie-lidmaatschap niet automatisch, het account moet ook push-rechten op de
+- **De registry** heeft geen eigen variabele nodig: `release.ps1` en `dev.ps1`
-repo hebben.
+  vallen bij een ontbrekende `REGISTRY_TOKEN` terug op `GITEA_TOKEN`. Zet alleen
+  `REGISTRY_USER` erbij, zodat het script zelf kan inloggen als de credential
+  store leeg is.
+- **De Docker-host** hoeft niets meer te hebben: pull en update-check zijn anoniem.
 
-**Waar ze terechtkomen**
+Aanmaken: Gitea → Settings → Applications → Generate New Token, met **beide**
+scopes aangevinkt. Doe dat onder een account dat push-rechten op de repo heeft —
+lid zijn van de organisatie is daarvoor niet automatisch genoeg. Scopes van een
+bestaand token zijn later niet aan te passen, dus vink ze in één keer goed aan.
 
-| | Werkstation | Docker-host |
+**Waar hij terechtkomt** — `.env.release` naast de scripts, niet in git
-|---|---|---|
+(`.gitignore` pakt `.env.*`):
-| Registry | `docker login` (credential store), of `REGISTRY_USER` + `REGISTRY_TOKEN` in `.env.release` | niets nodig voor een pull; anders `docker login` als de gebruiker die deployt |
-| Gitea-API | `GITEA_TOKEN` in `.env.release` | niets nodig; optioneel `UPDATE_CHECK_TOKEN` in `.env` |
 
-**Waarom een host-token read-only blijft** — voor het geval de organisatie weer
+```ini
-privé gaat en je er alsnog één neerzet. Dat staat in platte tekst in `.env` op
+GITEA_TOKEN=<token met write:package + write:repository>
-een server die de app op poort 3400 publiceert. Met schrijfrechten kan wie bij dat
+REGISTRY_USER=<je Gitea-account>
-bestand komt — via de container, een shell op die host, of een backup — een eigen
+```
-image als `latest` naar de registry pushen, en die host pullt `latest` zelf.
+
-Read-only houdt je eigen deploy-pad uit de aanvalsketen.
+Een variabele die al in je shell staat wint, zodat je per run kunt afwijken. Een
+lege waarde in het bestand wordt overgeslagen.
+
+**Als de organisatie weer privé gaat** heb je er wél een tweede bij nodig: een
+read-only token op de Docker-host, voor `docker compose pull` en
+`UPDATE_CHECK_TOKEN`. Houd dat token dan read-only. Het staat in platte tekst in
+`.env` op een server die de app op poort 3400 publiceert; met schrijfrechten kan
+wie bij dat bestand komt — via de container, een shell op die host, of een
+backup — een eigen image als `latest` naar de registry pushen, en die host pullt
+`latest` zelf. Read-only houdt je eigen deploy-pad uit de aanvalsketen.
 
 ### Wat een foutcode betekent
 
@@ -168,14 +177,21 @@ docker exec vibefinance_app node -e 'const t=process.env.UPDATE_CHECK_TOKEN; fet
 > waarde helemaal geen header. Nagemeten op 2026-09-10:
 > geen header `200`, `token ongeldig123` `401`, leeg `200`.
 
-### Tokens opruimen
+### Oude tokens opruimen
 
-De lijst onder Settings → Applications heeft een kolom **Last used**. Zet eerst
+Nu er één token overblijft, kunnen de rest weg — maar niet op de gok. De lijst
-beide machines om, draai daarna een release en een pull, en kijk een dag later
+onder Settings → Applications heeft een kolom **Last used**. Werkwijze:
-welke tokens niet meer meebewegen — die kun je intrekken. Betrouwbaarder dan uit
+
-de naam afleiden wat waar in gebruik is. Trek niets in vóór die controle: het
+1. Zet het nieuwe token in `.env.release` en draai een release die helemaal
-token achter je `docker login` op dit werkstation laat een release op de push
+   doorloopt (inclusief `docker push` en stap 5).
-falen.
+2. Kijk in de lijst welk token net **Last used** heeft gekregen.
+3. Wacht een dag en trek de tokens in die niet meer meebewegen.
+
+Betrouwbaarder dan uit de naam afleiden wat waar in gebruik is. Trek vooral niets
+in vóór die controle: het token achter je `docker login` zit in de credential
+store en niet in een bestand, dus je ziet aan niets welke het is — trek je die
+in, dan valt de push in stap 3 om. Loopt dat toch mis, dan is
+`docker login vibehoogie.duckdns.org` met het nieuwe token genoeg.
 
 ---
 
@@ -222,16 +238,15 @@ in de volgende commit.
 Staat er een `.env.release` naast `release.ps1`, dan leest het script die in
 voordat er iets gebeurt, en hoeft stap 3 niet meer met de hand:
 
-```
+```ini
 # .env.release — staat in .gitignore, hoort alleen op de release-machine
 GITEA_TOKEN=<vibefinance-workstation>
 REGISTRY_USER=<gitea-gebruiker>
-REGISTRY_TOKEN=<vibefinance-workstation>
 ```
 
-Beide tokenvariabelen krijgen hetzelfde token; zie [Tokens](#tokens) voor waarom
+`REGISTRY_TOKEN` hoeft er niet in: beide scripts vallen bij een ontbrekende
-dat op deze machine één token mag zijn, en voor wat een 401, 403 of 404 van Gitea
+`REGISTRY_TOKEN` terug op `GITEA_TOKEN`. Zie [Tokens](#tokens) voor de scopes en
-betekent.
+voor wat een 401, 403 of 404 van Gitea betekent.
 
 Een variabele die al in je shell staat wint, zodat je per run kunt afwijken zonder
 het bestand aan te passen. Het script logt alleen welke namen het heeft geladen,
@@ -430,8 +445,9 @@ machine — `vibefinance-workstation`, zie [Tokens](#tokens). Zonder login faalt
 een push met `401 Unauthorized`; `release.ps1` en `dev.ps1 push` controleren dit
 vóór de build en stoppen dan meteen.
 
-Liever niet handmatig inloggen? Zet `REGISTRY_USER` en `REGISTRY_TOKEN` in
+Liever niet handmatig inloggen? Zet `REGISTRY_USER` in `.env.release`, dan logt
-`.env.release`, dan logt het script zelf in.
+het script zelf in met `GITEA_TOKEN` — een aparte `REGISTRY_TOKEN` is alleen
+nodig als je daar bewust een ánder token voor wilt gebruiken.
 
 Twee valkuilen: log in op `vibehoogie.duckdns.org` **zonder** `:3000` (dat is een
 aparte sleutel in de credential store), en doe het als dezelfde Windows-gebruiker

Changelog.md

@@ -1,6 +1,6 @@
 # Changelog
 
-## [Niet vrijgegeven]
+## [1.0.1] - 2026-09-10
 
 ### Toegevoegd
 - Kolommen in de tabellen op Eigen Vermogen ("Geïnvesteerde Fiat") en Voortgang
@@ -17,6 +17,11 @@
   ondersteunt hem nog als vangnet voor het geval de organisatie weer privé
   wordt. Schrijven verandert niet: `docker push` en het aanmaken van een release
   hebben nog steeds het werkstation-token nodig
+- Het tweetoken-model in `BEHEER.md` is teruggebracht tot **één** Gitea-token op
+  het werkstation, met `write:package` en `write:repository`. Het host-token is
+  niet meer nodig (pull en update-check zijn anoniem), `git push` gaat over SSH,
+  en `REGISTRY_TOKEN` hoeft niet apart: `release.ps1` en `dev.ps1` vielen daar al
+  terug op `GITEA_TOKEN`. Geen code-wijziging, alleen minder te beheren
 - De tabellen op Eigen Vermogen en Voortgang staan op `table-layout: fixed`,
   nodig om ingestelde kolombreedtes te respecteren. Gevolg: lange tekst rekt een
   kolom niet meer op maar wordt afgekapt met een ellips. De Opmerkingen-cellen

README.md

@@ -10,7 +10,7 @@ Eigen vermogen · Schulden · Voortgang · Gebruikersbeheer
 ![Node.js](https://img.shields.io/badge/Node.js_22-339933?style=flat&logo=node.js&logoColor=white)
 ![PostgreSQL](https://img.shields.io/badge/PostgreSQL_18-4169E1?style=flat&logo=postgresql&logoColor=white)
 ![Docker](https://img.shields.io/badge/Docker_Compose-2496ED?style=flat&logo=docker&logoColor=white)
-![Version](https://img.shields.io/badge/versie-1.0.0-8b5cf6?style=flat)
+![Version](https://img.shields.io/badge/versie-1.0.1-8b5cf6?style=flat)
 ![Built with Claude](https://img.shields.io/badge/Gebouwd_met-Claude.ai-8b5cf6?style=flat&logo=anthropic&logoColor=white)
 
 <img src="docs/screenshot-dashboard.png" alt="VibeFinance dashboard" width="820">
@@ -121,7 +121,8 @@ backend/package.json (15 dependencies)
 
 ```powershell
 # token: staat in .env.release, of eenmalig in de shell
-$env:GITEA_TOKEN = "<token met write:repository>"
+# één Gitea-token met write:package (push) én write:repository (release)
+$env:GITEA_TOKEN = "<token met write:package + write:repository>"
 .\release.ps1
 ```
 
@@ -298,8 +299,9 @@ Het schema wordt bij het starten van de app aangemaakt/bijgewerkt via
 ## 🛠️ Beheer
 
 Zie `BEHEER.md` voor commando's voor lokale ontwikkeling, releases, logs en
-database-toegang — en voor de sectie **Tokens**: welk Gitea-token op welke
+database-toegang — en voor de sectie **Tokens**: waarom één Gitea-token op het
-machine hoort, met welke scopes, en wat een 401, 403 of 404 van Gitea betekent.
+werkstation genoeg is, welke scopes het nodig heeft, en wat een 401, 403 of 404
+van Gitea betekent.
 
 ---
 

frontend/package.json

@@ -1,6 +1,6 @@
 {
   "name": "vibefinance-frontend",
-  "version": "1.0.1-dev",
+  "version": "1.0.1",
   "private": true,
   "type": "module",
   "scripts": {