bugfix #7

Merged
jhoogie merged 1 commits from update-1.0.2 into main 2026-09-10 15:43:57 +02:00
6 changed files with 84 additions and 18 deletions
Showing only changes of commit 624f51679a - Show all commits
+63 -8
View File
@@ -108,7 +108,19 @@ is schrijven, en dat gebeurt allemaal vanaf deze ene machine.
Er is geen apart host-token en geen apart registry-token: Er is geen apart host-token en geen apart registry-token:
- **`git push`** gaat over SSH (`gitea@…:Vibe/VibeFinance.git`), dus die gebruikt - **`git push`** gaat over SSH (`gitea@…:Vibe/VibeFinance.git`), dus die gebruikt
je SSH-sleutel en niet dit token. 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:
```powershell
git fetch https://vibehoogie.duckdns.org/Vibe/VibeFinance.git --prune --tags "+refs/heads/*:refs/remotes/origin/*"
```
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` - **De registry** heeft geen eigen variabele nodig: `release.ps1` en `dev.ps1`
vallen bij een ontbrekende `REGISTRY_TOKEN` terug op `GITEA_TOKEN`. Zet alleen vallen bij een ontbrekende `REGISTRY_TOKEN` terug op `GITEA_TOKEN`. Zet alleen
`REGISTRY_USER` erbij, zodat het script zelf kan inloggen als de credential `REGISTRY_USER` erbij, zodat het script zelf kan inloggen als de credential
@@ -143,21 +155,28 @@ backup — een eigen image als `latest` naar de registry pushen, en die host pul
| Status | Betekenis | | Status | Betekenis |
|---|---| |---|---|
| 401 | Token ongeldig of verlopen. Op de registry: helemaal niet ingelogd. | | 401 | Token ongeldig, verlopen of ingetrokken — Gitea herkent hem niet. 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. | | 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. | | 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 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. 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 ```powershell
$h = @{ Authorization = "token $env:GITEA_TOKEN" } $u = "https://vibehoogie.duckdns.org/api/v1/user/repos"
(Invoke-RestMethod https://vibehoogie.duckdns.org/api/v1/user -Headers $h).login try { (Invoke-WebRequest $u -Headers @{ Authorization = "token $env:GITEA_TOKEN" } -UseBasicParsing).StatusCode }
(Invoke-RestMethod https://vibehoogie.duckdns.org/api/v1/user/repos -Headers $h).full_name 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 — 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: busybox-`wget` gooit die bij een foutstatus weg, en Node zit in het image:
@@ -505,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). 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` 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** **Configuratie**
+14
View File
@@ -1,5 +1,19 @@
# Changelog # Changelog
## [Niet vrijgegeven]
### Gewijzigd
- De update-melding op het belletje toont alleen nog de kop, de versieregel en de
link naar de release. De release-notes stonden er als ruwe Markdown in — in een
kaart van 280px leverde dat zichtbare `### `-koppen en afgekapte regels op.
`/api/update-check` stuurt `notes` nog wel mee, zodat ze later ergens met meer
ruimte gebruikt kunnen worden
- `BEHEER.md` legt vast dat de release-link uit Gitea's `ROOT_URL` wordt
samengesteld en niet per release wordt opgeslagen: na een `ROOT_URL`-wijziging
plus herstart zijn álle releases in één keer goed, ook de oude. Verder staat er
nu hoe je aan het verschil tussen `401` en `403` ziet of een token nog leeft, en
hoe je anoniem over https fetcht als SSH niet meedoet
## [1.0.1] - 2026-09-10 ## [1.0.1] - 2026-09-10
### Toegevoegd ### Toegevoegd
+1
View File
@@ -171,6 +171,7 @@ vibefinance/
│ ├── vite.config.js # /api proxy naar de API in dezelfde container │ ├── vite.config.js # /api proxy naar de API in dezelfde container
│ └── src/ │ └── src/
│ ├── App.jsx # Root – wiring + idle-logout │ ├── App.jsx # Root – wiring + idle-logout
│ ├── App.css # Reset + losse klassen (o.a. .kolom-grip)
│ ├── main.jsx │ ├── main.jsx
│ ├── version.js # Draaiende versie (__APP_VERSION__ uit de build) │ ├── version.js # Draaiende versie (__APP_VERSION__ uit de build)
│ ├── constants/ # Kleuren, tabs, begindata │ ├── constants/ # Kleuren, tabs, begindata
+1 -1
View File
@@ -1,6 +1,6 @@
{ {
"name": "vibefinance-frontend", "name": "vibefinance-frontend",
"version": "1.0.1", "version": "1.0.2-dev",
"private": true, "private": true,
"type": "module", "type": "module",
"scripts": { "scripts": {
+4 -8
View File
@@ -209,14 +209,10 @@ function AppInner() {
<div style={{ fontSize: 12, color: T.muted, lineHeight: 1.5 }}> <div style={{ fontSize: 12, color: T.muted, lineHeight: 1.5 }}>
v{nieuweVersie.latest} is uitgebracht. Je gebruikt momenteel v{version}. v{nieuweVersie.latest} is uitgebracht. Je gebruikt momenteel v{version}.
</div> </div>
{nieuweVersie.notes && ( {/* De release-notes zelf staan hier niet: dat is Markdown
<div style={{ uit de changelog, en die kwam als ruwe `### `-koppen in
fontSize: 11, color: T.subtext, marginTop: 6, lineHeight: 1.5, een smalle kolom te staan. Wie de details wil, volgt de
maxHeight: 130, overflowY: "auto", whiteSpace: "pre-wrap", link naar de release. */}
}}>
{nieuweVersie.notes}
</div>
)}
{nieuweVersie.url && ( {nieuweVersie.url && (
<a href={nieuweVersie.url} target="_blank" rel="noreferrer" style={{ <a href={nieuweVersie.url} target="_blank" rel="noreferrer" style={{
display: "inline-block", marginTop: 8, display: "inline-block", marginTop: 8,
+1 -1
View File
@@ -1,6 +1,6 @@
{ {
"name": "vibefinance", "name": "vibefinance",
"version": "1.0.2-dev", "version": "1.0.2",
"description": "VibeFinance — persoonlijk vermogensbeheer", "description": "VibeFinance — persoonlijk vermogensbeheer",
"private": true, "private": true,
"repository": "https://vibehoogie.duckdns.org/vibe/VibeFinance", "repository": "https://vibehoogie.duckdns.org/vibe/VibeFinance",