|
|
|
@@ -96,59 +96,87 @@ 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
|
|
|
|
|
> daardoor geen token meer nodig: `git clone`, `docker compose pull` en de
|
|
|
|
|
> update-check van de app werken anoniem. Het host-token hieronder is dus
|
|
|
|
|
> optioneel geworden. *Schrijven* blijft geauthenticeerd — een publieke
|
|
|
|
|
> organisatie verandert daar niets aan.
|
|
|
|
|
**Eén token, op het werkstation.** Dat is genoeg omdat de `Vibe`-organisatie op
|
|
|
|
|
public staat: alles wat alleen *leest* heeft geen token meer nodig — `git clone`,
|
|
|
|
|
`docker compose pull` en de update-check van de app werken anoniem. Wat overblijft
|
|
|
|
|
is schrijven, en dat gebeurt allemaal vanaf deze ene machine.
|
|
|
|
|
|
|
|
|
|
Twee tokens, gesplitst op machine en op read/write. De grens die iets betekent
|
|
|
|
|
ligt tussen werkstation en server, niet tussen push en release: op één machine
|
|
|
|
|
kan wie het ene token kan lezen, het andere ook.
|
|
|
|
|
| Token | Machine | Scopes | Gebruikt voor |
|
|
|
|
|
|---|---|---|---|
|
|
|
|
|
| `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? |
|
|
|
|
|
|---|---|---|---|---|
|
|
|
|
|
| `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 |
|
|
|
|
|
Er is geen apart host-token en geen apart registry-token:
|
|
|
|
|
|
|
|
|
|
Aanmaken: Gitea → Settings → Applications → Generate New Token. Doe dat onder een
|
|
|
|
|
account dat lid is van de `Vibe`-organisatie: voor schrijven volstaat
|
|
|
|
|
organisatie-lidmaatschap niet automatisch, het account moet ook push-rechten op de
|
|
|
|
|
repo hebben.
|
|
|
|
|
- **`git push`** gaat over SSH (`gitea@…:Vibe/VibeFinance.git`), dus die gebruikt
|
|
|
|
|
je SSH-sleutel en niet dit token. Werkt SSH even niet — bijvoorbeeld omdat de
|
|
|
|
|
ssh-agent niet meedoet in een niet-interactieve shell, wat `Permission denied
|
|
|
|
|
(publickey,password)` geeft — dan kun je *lezen* nu anoniem over https, omdat
|
|
|
|
|
de organisatie public is:
|
|
|
|
|
|
|
|
|
|
**Waar ze terechtkomen**
|
|
|
|
|
```powershell
|
|
|
|
|
git fetch https://vibehoogie.duckdns.org/Vibe/VibeFinance.git --prune --tags "+refs/heads/*:refs/remotes/origin/*"
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
| | Werkstation | Docker-host |
|
|
|
|
|
|---|---|---|
|
|
|
|
|
| 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` |
|
|
|
|
|
Die refspec werkt ook `origin/*` bij, dus daarna doen `git merge --ff-only
|
|
|
|
|
origin/main` en `git log origin/main` het weer. Pushen blijft SSH; `release.ps1`
|
|
|
|
|
leest daarvoor `core.sshCommand` uit, omdat op Windows alleen de OpenSSH van het
|
|
|
|
|
systeem met de ssh-agent praat en Git's eigen `ssh` niet.
|
|
|
|
|
- **De registry** heeft geen eigen variabele nodig: `release.ps1` en `dev.ps1`
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
**Waarom een host-token read-only blijft** — voor het geval de organisatie weer
|
|
|
|
|
privé gaat en je er alsnog één neerzet. Dat 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.
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
**Waar hij terechtkomt** — `.env.release` naast de scripts, niet in git
|
|
|
|
|
(`.gitignore` pakt `.env.*`):
|
|
|
|
|
|
|
|
|
|
```ini
|
|
|
|
|
GITEA_TOKEN=<token met write:package + write:repository>
|
|
|
|
|
REGISTRY_USER=<je Gitea-account>
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
|
|
| Status | Betekenis |
|
|
|
|
|
|---|---|
|
|
|
|
|
| 401 | Token ongeldig of verlopen. Op de registry: helemaal niet ingelogd. |
|
|
|
|
|
| 403 | Het token mag de repo wél zien, maar mist de **scope** voor dit endpoint. Gitea noemt de vereiste scope in de response-body. |
|
|
|
|
|
| 401 | Token ongeldig, verlopen of ingetrokken — Gitea herkent hem niet. Op de registry: helemaal niet ingelogd. |
|
|
|
|
|
| 403 | Het token **bestaat en werkt**, maar mist de **scope** voor dit endpoint. Gitea noemt de vereiste scope in de response-body. |
|
|
|
|
|
| 404 | Het token mag de repo niet zien. Gitea geeft geen 403, om niet te verklappen dat iets bestaat: verkeerd account, of geen toegang tot de organisatie. Nu de organisatie public is, wijst een 404 op een leesactie eerder op een verkeerde URL dan op rechten. |
|
|
|
|
|
|
|
|
|
|
Scopes van een bestaand token zijn in Gitea niet aan te passen. Bij een 403 maak
|
|
|
|
|
je dus een nieuw token aan; bijwerken kan niet.
|
|
|
|
|
|
|
|
|
|
Nakijken wie een token is en wat hij ziet:
|
|
|
|
|
**Leeft mijn token nog?** Juist dat onderscheid tussen 401 en 403 is de test.
|
|
|
|
|
Vraag *niet* `/api/v1/user` op om te kijken "wie het token is": het
|
|
|
|
|
werkstation-token heeft geen `read:user`, dus dat endpoint geeft altijd 403 en
|
|
|
|
|
zegt niets over geldigheid. Kijk naar de statuscode, niet naar de inhoud:
|
|
|
|
|
|
|
|
|
|
```powershell
|
|
|
|
|
$h = @{ Authorization = "token $env:GITEA_TOKEN" }
|
|
|
|
|
(Invoke-RestMethod https://vibehoogie.duckdns.org/api/v1/user -Headers $h).login
|
|
|
|
|
(Invoke-RestMethod https://vibehoogie.duckdns.org/api/v1/user/repos -Headers $h).full_name
|
|
|
|
|
$u = "https://vibehoogie.duckdns.org/api/v1/user/repos"
|
|
|
|
|
try { (Invoke-WebRequest $u -Headers @{ Authorization = "token $env:GITEA_TOKEN" } -UseBasicParsing).StatusCode }
|
|
|
|
|
catch { $_.Exception.Response.StatusCode.value__ }
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
`403` = het token leeft (alleen deze scope ontbreekt). `401` = ingetrokken of
|
|
|
|
|
fout gekopieerd. Nagemeten op 2026-09-10: geen header `401`, een nep-token van 40
|
|
|
|
|
nullen `401`, het werkstation-token `403`.
|
|
|
|
|
|
|
|
|
|
Vanuit de app-container op de host valt de body van een fout anders weg —
|
|
|
|
|
busybox-`wget` gooit die bij een foutstatus weg, en Node zit in het image:
|
|
|
|
|
|
|
|
|
@@ -168,14 +196,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
|
|
|
|
|
beide machines om, draai daarna een release en een pull, en kijk een dag later
|
|
|
|
|
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
|
|
|
|
|
token achter je `docker login` op dit werkstation laat een release op de push
|
|
|
|
|
falen.
|
|
|
|
|
Nu er één token overblijft, kunnen de rest weg — maar niet op de gok. De lijst
|
|
|
|
|
onder Settings → Applications heeft een kolom **Last used**. Werkwijze:
|
|
|
|
|
|
|
|
|
|
1. Zet het nieuwe token in `.env.release` en draai een release die helemaal
|
|
|
|
|
doorloopt (inclusief `docker push` en stap 5).
|
|
|
|
|
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 +257,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
|
|
|
|
|
dat op deze machine één token mag zijn, en voor wat een 401, 403 of 404 van Gitea
|
|
|
|
|
betekent.
|
|
|
|
|
`REGISTRY_TOKEN` hoeft er niet in: beide scripts vallen bij een ontbrekende
|
|
|
|
|
`REGISTRY_TOKEN` terug op `GITEA_TOKEN`. Zie [Tokens](#tokens) voor de scopes en
|
|
|
|
|
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 +464,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
|
|
|
|
|
`.env.release`, dan logt het script zelf in.
|
|
|
|
|
Liever niet handmatig inloggen? Zet `REGISTRY_USER` in `.env.release`, dan logt
|
|
|
|
|
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
|
|
|
|
@@ -489,7 +524,43 @@ dat op het belletje in de topbalk en onder "Over VibeFinance".
|
|
|
|
|
|
|
|
|
|
Builds met een `-dev` suffix melden nooit (die lopen voor op de laatste release).
|
|
|
|
|
Wil je de melding tijdens ontwikkeling toch testen: open de app met `?updatecheck`
|
|
|
|
|
in de URL.
|
|
|
|
|
in de URL. Let op dat `isNieuwer` alleen bij een écht hoger nummer aanslaat — bij
|
|
|
|
|
`1.0.2-dev` naast release `1.0.1` blijft de kaart dus ook met `?updatecheck` leeg.
|
|
|
|
|
Zet dan tijdelijk een lagere versie in de root `package.json`.
|
|
|
|
|
|
|
|
|
|
**Wat de melding toont**
|
|
|
|
|
|
|
|
|
|
Alleen de kop, de versieregel en een link:
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
🔔 Nieuwe versie beschikbaar
|
|
|
|
|
v1.0.1 is uitgebracht. Je gebruikt momenteel v1.0.0.
|
|
|
|
|
Release bekijken →
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
De release-notes staan er bewust **niet** in. `/api/update-check` stuurt ze wel
|
|
|
|
|
mee als `notes`, maar dat is de ruwe Markdown uit de changelog; in een kaart van
|
|
|
|
|
280px leverde dat zichtbare `### `-koppen en afgekapte regels op. Wie de details
|
|
|
|
|
wil, volgt de link. Het veld blijft in de API zitten voor het geval je ze ooit
|
|
|
|
|
ergens met meer ruimte wilt tonen — dan is Markdown renderen de volgende stap.
|
|
|
|
|
|
|
|
|
|
**De release-link hangt aan Gitea's `ROOT_URL`**
|
|
|
|
|
|
|
|
|
|
De `url` in het antwoord is de `html_url` van de release, en die stelt Gitea bij
|
|
|
|
|
elk verzoek samen uit `ROOT_URL` in `app.ini` — hij wordt *niet* per release
|
|
|
|
|
opgeslagen. Staat `ROOT_URL` op een intern adres, dan wijst "Release bekijken"
|
|
|
|
|
naar iets dat buiten je netwerk niet bestaat, terwijl de melding zelf gewoon
|
|
|
|
|
werkt (die leest alleen het versienummer).
|
|
|
|
|
|
|
|
|
|
Nakijken welke waarde Gitea daadwerkelijk gebruikt — de `issuer` is `ROOT_URL`:
|
|
|
|
|
|
|
|
|
|
```bash
|
|
|
|
|
curl -s https://vibehoogie.duckdns.org/.well-known/openid-configuration | grep issuer
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
`app.ini` wordt alleen bij het opstarten gelezen, dus na een wijziging moet Gitea
|
|
|
|
|
herstarten. Omdat de URL wordt samengesteld en niet bewaard, zijn daarna álle
|
|
|
|
|
releases in één keer goed — ook de oude. Een `PATCH` per release is niet nodig.
|
|
|
|
|
|
|
|
|
|
**Configuratie**
|
|
|
|
|
|
|
|
|
|
Jordy Hoogeveen
jhoogie