Kaal gaan haalt de enige bescherming weg die er nu is
Richting van de gebruiker: de kale Evolu-relay, met een eigen limiter erop en de statuspagina uit open punt 2. Vastgelegd, niet gebouwd; de app staat uit en er gebeurt vandaag niets meer aan. Het inzicht dat die drie aan elkaar knoopt staat er nu bij. De kale relay heeft geen toegangscontrole, en dat is bij Evolu het ontwerp en geen omissie. Wat vandaag de schade beperkt is juist een applicatiecontrole: Trezor's relay weigert elke eigenaar zonder limietenrij. Kaal gaan haalt precies die weg, dus de limiter is de vervanging ervan en geen extraatje. De statuspagina krijgt er een taak bij: tonen welke eigenaar toegelaten is, met de knop om die keuze te wissen. Twee dingen die makkelijk verkeerd onthouden worden, daarom expliciet. De quota-manager die er nu in zit is niet te hergebruiken: die schrijft in Trezor's limietentabel en die tabel bestaat straks niet meer. En de meest voor de hand liggende limiter breidt de relay uit via createRelay, dus de bouwstap en het eigen register komen dan terug; de gebruiker meldt dat de broncode nog op zijn Umbrel staat, dus dat is geen obstakel. Postgres en het wachtwoord vervallen sowieso. Het blijft een richting en geen besluit: de protocolproef is niet gedaan, en die blijft de eerste taak. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
@@ -21,8 +21,24 @@
|
||||
`docker run --rm -p 4000:4000 docker.io/evoluhq/relay:latest`, Suite ernaartoe wijzen onder
|
||||
**dev-utils**, label maken. **Eigenaar: gebruiker**
|
||||
- [ ] **Pas daarna beslissen wat er met het huidige pakket gebeurt.** Werkt de kale relay, dan wordt dit
|
||||
één container op een gepubliceerde image en vervallen de bouwstap, het eigen register, de Postgres en
|
||||
het wachtwoord. Werkt hij niet, dan is de limietenrij met de hand zetten de enige weg vooruit
|
||||
één container op een gepubliceerde image en vervallen de Postgres en het wachtwoord. Werkt hij niet,
|
||||
dan is de limietenrij met de hand zetten de enige weg vooruit
|
||||
|
||||
**De richting is al gekozen op 27-08-2026: kaal, met een eigen limiter erop en de statuspagina
|
||||
erbij.** Zie [OPEN.md](OPEN.md) punt 6, 8 en 2. Wat daarbij vastligt en makkelijk verkeerd onthouden
|
||||
wordt: de kale relay heeft géén toegangscontrole, dus de limiter is geen extraatje maar de vervanging
|
||||
van de enige bescherming die er vandaag is. En de quota-manager die er nu in zit is daarvoor niet te
|
||||
hergebruiken: die schrijft in Trezor's limietentabel, en die tabel bestaat straks niet meer
|
||||
|
||||
**Een eigen image blijft daardoor waarschijnlijk nodig**, want de meest voor de hand liggende limiter
|
||||
breidt de relay uit via `createRelay`. Dat is geen obstakel: de gebruiker meldde op 27-08-2026 dat de
|
||||
broncode nog op zijn Umbrel staat, dus opnieuw bouwen en naar het eigen Gitea-register duwen kan
|
||||
gewoon. De bouwstap en het register vervallen dus mogelijk tóch niet; de Postgres en het wachtwoord
|
||||
wel
|
||||
|
||||
- [ ] **De limiter kiezen uit de drie wegen van Bereikbaarheid §4b**, met de leer-variant erbij: de eerste
|
||||
eigenaar die verbindt wordt toegelaten, de rest geweigerd, met een wisknop op de statuspagina. Zie
|
||||
[OPEN.md](OPEN.md) punt 8. **Pas nadat de proef geslaagd is**
|
||||
- [ ] **In de logs van de relay kijken of het databaseschema zichzelf aanmaakt.** Alleen nog nuttig als het
|
||||
huidige pakket blijft: `sudo docker logs whatsnext-evolu-relay_relay_1`
|
||||
|
||||
|
||||
Reference in New Issue
Block a user