iris/Iris
1
0
Fork 0
Code Issues 23 Pull requests Projects Releases Packages Wiki Activity Actions

Git-Server: Zugriffs-Token häufen sich (jedes Anmelden und Bereitstellen legt ein neues an) #230

New issue
Closed
opened 2026-10-28 16:12:56 +00:00 by alf · 3 comments
alf commented 2026-10-28 16:12:56 +00:00
Owner
Copy link

Aufgefallen beim Test des Serverwechsels (iris/Iris#223): Im Fenster Einstellungen → Git-Server → Verbundene Rechner stehen 13 Einträge, obwohl nur zwei Rechner (Mac Studio, VM) verbunden sind.

Befund (am Code und an der echten Liste von iris-server geprüft)

  • Jedes „Anmelden“ im Fenster „Vault verbinden“ (forge/login) legt ein Forgejo-Token Iris Vault-Sync – <Rechnername> (<Zeitpunkt>) an. Es wird nie widerrufen: nicht nach dem Verbinden, nicht bei Abbruch, nicht beim nächsten Anmelden desselben Rechners.
  • „Auf diesem Rechner bereitstellen“ (publish_vault / Mac-Gegenstück) legt jedes Mal ein weiteres Token Iris Vault (dieser Rechner) <Zeitpunkt> <hex> an; diese lassen sich in der Oberfläche nicht entziehen.
  • Ergebnis heute: 5× Mac Studio, 3× VM, 5× „dieser Rechner“. „zuletzt benutzt“ steht bei allen auf „nie“ (auch bei in Gebrauch befindlichen), daran ist nichts erkennbar.

Ziel

Pro Rechner bleibt höchstens das Token in Gebrauch plus ein nicht abgeschlossenes. Das Token, mit dem ein Rechner gerade verbunden ist, wird nie widerrufen (sonst meldet der Rechner „Token abgelehnt“).

Entwurf

Die Token-Verwaltung der Forgejo-API verlangt das Passwort (Basic-Auth). Das Passwort wird aber nie gespeichert (Regel aus #76), also kann aufgeräumt werden nur, solange es vorliegt:

  1. Beim Anmelden (forge/login): Vor dem Anlegen des neuen Tokens die Token-Liste lesen und alle Token mit dem Namensanfang dieses Rechners (Iris Vault-Sync – <Rechnername> () widerrufen, außer dem, das dieser Rechner gerade verwendet (Abgleich über die letzten 8 Zeichen: Forgejo liefert token_last_eight, die gespeicherten Zugangsdaten kennen das Token). Ein abgebrochenes Anmelden hinterlässt damit höchstens ein Token, das beim nächsten Anmelden verschwindet.
  2. Beim Bereitstellen auf diesem Rechner: Das Passwort des eigenen Git-Servers liegt vor. Das neue Token wird angelegt, nach erfolgreichem Verbinden werden alle anderen Iris Vault (dieser Rechner)-Token widerrufen; scheitert das Verbinden, wird das neue sofort widerrufen.
  3. Zwei-Faktor: Forgejo lehnt einen Zwei-Faktor-Code ein zweites Mal ab. Mit Code wird deshalb nicht aufgeräumt (nur das eine Anlegen). Konten mit Zwei-Faktor sammeln weiter Token; „Zugang entziehen“ bleibt der Weg.
  4. Fehler beim Aufräumen sind kein Fehler beim Anmelden (nur Logzeile).

Gilt für Linux-Server (vault_forge.py, forgejo_service.py) und Mac-Server (VaultSyncCore.swift/ForgejoCore.swift).

Nicht Teil dieses Issues

Bereits vorhandene Altlasten werden nicht automatisch entfernt; der Nutzer entzieht sie einmalig über „Zugang entziehen“ (das jeweils neueste Token pro Rechner behalten).

Aufgefallen beim Test des Serverwechsels (iris/Iris#223): Im Fenster **Einstellungen → Git-Server → Verbundene Rechner** stehen 13 Einträge, obwohl nur zwei Rechner (Mac Studio, VM) verbunden sind. ## Befund (am Code und an der echten Liste von iris-server geprüft) - Jedes „Anmelden“ im Fenster „Vault verbinden“ (`forge/login`) legt ein Forgejo-Token `Iris Vault-Sync – <Rechnername> (<Zeitpunkt>)` an. Es wird nie widerrufen: nicht nach dem Verbinden, nicht bei Abbruch, nicht beim nächsten Anmelden desselben Rechners. - „Auf diesem Rechner bereitstellen“ (`publish_vault` / Mac-Gegenstück) legt jedes Mal ein weiteres Token `Iris Vault (dieser Rechner) <Zeitpunkt> <hex>` an; diese lassen sich in der Oberfläche nicht entziehen. - Ergebnis heute: 5× Mac Studio, 3× VM, 5× „dieser Rechner“. „zuletzt benutzt“ steht bei allen auf „nie“ (auch bei in Gebrauch befindlichen), daran ist nichts erkennbar. ## Ziel Pro Rechner bleibt höchstens das Token in Gebrauch plus ein nicht abgeschlossenes. Das Token, mit dem ein Rechner gerade verbunden ist, wird nie widerrufen (sonst meldet der Rechner „Token abgelehnt“). ## Entwurf Die Token-Verwaltung der Forgejo-API verlangt das Passwort (Basic-Auth). Das Passwort wird aber nie gespeichert (Regel aus #76), also kann aufgeräumt werden nur, solange es vorliegt: 1. **Beim Anmelden (`forge/login`):** Vor dem Anlegen des neuen Tokens die Token-Liste lesen und alle Token mit dem Namensanfang dieses Rechners (`Iris Vault-Sync – <Rechnername> (`) widerrufen, **außer** dem, das dieser Rechner gerade verwendet (Abgleich über die letzten 8 Zeichen: Forgejo liefert `token_last_eight`, die gespeicherten Zugangsdaten kennen das Token). Ein abgebrochenes Anmelden hinterlässt damit höchstens ein Token, das beim nächsten Anmelden verschwindet. 2. **Beim Bereitstellen auf diesem Rechner:** Das Passwort des eigenen Git-Servers liegt vor. Das neue Token wird angelegt, nach erfolgreichem Verbinden werden alle anderen `Iris Vault (dieser Rechner)`-Token widerrufen; scheitert das Verbinden, wird das neue sofort widerrufen. 3. **Zwei-Faktor:** Forgejo lehnt einen Zwei-Faktor-Code ein zweites Mal ab. Mit Code wird deshalb nicht aufgeräumt (nur das eine Anlegen). Konten mit Zwei-Faktor sammeln weiter Token; „Zugang entziehen“ bleibt der Weg. 4. Fehler beim Aufräumen sind kein Fehler beim Anmelden (nur Logzeile). Gilt für Linux-Server (`vault_forge.py`, `forgejo_service.py`) und Mac-Server (`VaultSyncCore.swift`/`ForgejoCore.swift`). ## Nicht Teil dieses Issues Bereits vorhandene Altlasten werden nicht automatisch entfernt; der Nutzer entzieht sie einmalig über „Zugang entziehen“ (das jeweils neueste Token pro Rechner behalten).
alf commented 2026-10-28 16:20:59 +00:00
Author
Owner
Copy link

PR #121 gemergt: iris/Iris#230
iris/iris-linux-server#121

Commits:

PR #121 gemergt: iris/Iris#230 https://forgejo.lewerken.duckdns.org/iris/iris-linux-server/pulls/121 Commits: - iris/Iris#230
alf referenced this issue from a commit 2026-10-28 16:20:59 +00:00
iris/Iris#230
alf commented 2026-10-28 16:21:01 +00:00
Author
Owner
Copy link

PR #231 gemergt: fix(git-server): alte Zugriffs-Token beim Anmelden und Bereitstellen widerrufen (#230)
#231

Commits:

  • fix(git-server): alte Zugriffs-Token beim Anmelden und Bereitstellen widerrufen (#230)

Stand 2026-10-28: Token-Aufräumen, Linux-Server und Mac-Server

  • Geändert: forge/login räumt vor dem Anlegen des neuen Tokens die älteren Token dieses Rechners auf: Token-Liste lesen (seitenweise), alle mit dem Namensanfang Iris Vault-Sync – <Rechnername> ( widerrufen, außer dem, dessen letzte 8 Zeichen (token_last_eight) zum gerade gespeicherten Zugangs-Token dieses Rechners für diesen Server passen. Fehlt token_last_eight und es gibt ein aktives Token, wird nichts widerrufen. Mit Zwei-Faktor-Code entfällt das Aufräumen (Forgejo nimmt einen Code nur einmal an). Fehler beim Aufräumen sind kein Anmeldefehler. „Auf diesem Rechner bereitstellen“ räumt auf dieselbe Weise die älteren Iris Vault (dieser Rechner)-Token (Namensanfang als Konstante OWN_TOKEN_PREFIX bzw. ForgejoCore.ownTokenPrefix). Linux-Server: vault_forge.py, forgejo_service.py; Mac-Server: VaultSyncCore.swift, ForgejoCore.swift, ForgejoController.swift.
  • Abweichung vom Entwurf im Issue: Das Aufräumen passiert beim nächsten Anmelden bzw. Bereitstellen, nicht nach dem Verbinden. Nach dem Verbinden liegt das Passwort nicht mehr vor (es wird nie gespeichert), und Forgejo verlangt es für die Token-Verwaltung. Folge: Pro Rechner bleibt das aktive Token plus höchstens eines, das beim nächsten Anmelden verschwindet.
  • Geprüft: Linux-Server tests/test_vault_git_sync.py und tests/test_vault_sync_routes.py (88 grün, 1 übersprungen), tests/test_forgejo_service.py (25 grün); Mac-Kern scripts/test-vault-sync-core.sh (232 Prüfungen, 0 Fehler), scripts/test-forgejo-core.sh (41 Prüfungen, 0 Fehler; der Lauf gegen einen echten Forgejo wurde übersprungen, IRIS_FORGEJO_BINARY nicht gesetzt); Schemes Iris und IrisClient bauen. Neu getestet (gegen Attrappen): fremde Token und Token des Nutzers bleiben, das aktive bleibt, ohne token_last_eight bleibt alles, mit Code kein Aufräumen, Fehler beim Aufräumen bricht die Anmeldung nicht ab.
  • Nicht geprüft: gegen einen echten Forgejo (insbesondere, dass token_last_eight in der Liste steht und dass Forgejo das Löschen mit Passwort wie erwartet annimmt); iris-server (nicht deployt); die Mac-App (nicht gestartet). Die 13 vorhandenen Token auf iris-server bleiben, bis sie jemand über „Zugang entziehen“ entzieht (Entwurf: keine automatische Altlast-Bereinigung).
PR #231 gemergt: fix(git-server): alte Zugriffs-Token beim Anmelden und Bereitstellen widerrufen (#230) https://forgejo.lewerken.duckdns.org/iris/Iris/pulls/231 Commits: - fix(git-server): alte Zugriffs-Token beim Anmelden und Bereitstellen widerrufen (#230) --- **Stand 2026-10-28: Token-Aufräumen, Linux-Server und Mac-Server** - **Geändert:** `forge/login` räumt vor dem Anlegen des neuen Tokens die älteren Token dieses Rechners auf: Token-Liste lesen (seitenweise), alle mit dem Namensanfang `Iris Vault-Sync – <Rechnername> (` widerrufen, **außer** dem, dessen letzte 8 Zeichen (`token_last_eight`) zum gerade gespeicherten Zugangs-Token dieses Rechners für diesen Server passen. Fehlt `token_last_eight` und es gibt ein aktives Token, wird nichts widerrufen. Mit Zwei-Faktor-Code entfällt das Aufräumen (Forgejo nimmt einen Code nur einmal an). Fehler beim Aufräumen sind kein Anmeldefehler. „Auf diesem Rechner bereitstellen“ räumt auf dieselbe Weise die älteren `Iris Vault (dieser Rechner)`-Token (Namensanfang als Konstante `OWN_TOKEN_PREFIX` bzw. `ForgejoCore.ownTokenPrefix`). Linux-Server: `vault_forge.py`, `forgejo_service.py`; Mac-Server: `VaultSyncCore.swift`, `ForgejoCore.swift`, `ForgejoController.swift`. - **Abweichung vom Entwurf im Issue:** Das Aufräumen passiert beim **nächsten** Anmelden bzw. Bereitstellen, nicht nach dem Verbinden. Nach dem Verbinden liegt das Passwort nicht mehr vor (es wird nie gespeichert), und Forgejo verlangt es für die Token-Verwaltung. Folge: Pro Rechner bleibt das aktive Token plus höchstens eines, das beim nächsten Anmelden verschwindet. - **Geprüft:** Linux-Server `tests/test_vault_git_sync.py` und `tests/test_vault_sync_routes.py` (88 grün, 1 übersprungen), `tests/test_forgejo_service.py` (25 grün); Mac-Kern `scripts/test-vault-sync-core.sh` (232 Prüfungen, 0 Fehler), `scripts/test-forgejo-core.sh` (41 Prüfungen, 0 Fehler; der Lauf gegen einen echten Forgejo wurde übersprungen, `IRIS_FORGEJO_BINARY` nicht gesetzt); Schemes Iris und IrisClient bauen. Neu getestet (gegen Attrappen): fremde Token und Token des Nutzers bleiben, das aktive bleibt, ohne `token_last_eight` bleibt alles, mit Code kein Aufräumen, Fehler beim Aufräumen bricht die Anmeldung nicht ab. - **Nicht geprüft:** gegen einen echten Forgejo (insbesondere, dass `token_last_eight` in der Liste steht und dass Forgejo das Löschen mit Passwort wie erwartet annimmt); iris-server (nicht deployt); die Mac-App (nicht gestartet). Die 13 vorhandenen Token auf iris-server bleiben, bis sie jemand über „Zugang entziehen“ entzieht (Entwurf: keine automatische Altlast-Bereinigung).
alf commented 2026-10-28 16:34:43 +00:00
Author
Owner
Copy link

Stand 2026-10-28: Images veröffentlicht, latest gesetzt

  • Was draußen ist: Die sechs Linux-Server-Images (iris-server, iris-hermes, iris-tunnel, iris-hermes-sandbox, iris-web-automation, iris-browser) liegen als v1.6.59 in der Forgejo-Registry (forgejo.lewerken.duckdns.org/iris/…), der Git-Tag v1.6.59 ist gepusht, und latest zeigt auf v1.6.59 (zuvor v1.6.58). Der Build lief auf dem Entwicklungshost alf@iris-server.
  • Enthalten: Serverwechsel mit fremder Historie, Vault nur mit Dateien (iris/Iris#223), Wahl both in resolve, Aufräumen alter Git-Server-Token beim Anmelden und Bereitstellen (iris/Iris#230).
  • Was Nutzer bekommen: Neue Linux-Server-Instanzen und Aktualisierungen über die Registry holen diesen Stand. Die Mac-App und IrisRemote sind davon getrennt (nicht mit-veröffentlicht).
  • Geprüft: Build und Push aller sechs Images ohne Fehler, die Tags stehen in der Registry. Der Server lief schon vor dem Build mit demselben Quelltext auf iris-server (/health ok).
  • Nicht geprüft: ein frischer Start aus den veröffentlichten Images, eine Aktualisierung einer bestehenden Instanz über die Registry, der Serverwechsel gegen einen echten Forgejo mit großem Vault.
**Stand 2026-10-28: Images veröffentlicht, `latest` gesetzt** - **Was draußen ist:** Die sechs Linux-Server-Images (`iris-server`, `iris-hermes`, `iris-tunnel`, `iris-hermes-sandbox`, `iris-web-automation`, `iris-browser`) liegen als **v1.6.59** in der Forgejo-Registry (`forgejo.lewerken.duckdns.org/iris/…`), der Git-Tag `v1.6.59` ist gepusht, und `latest` zeigt auf v1.6.59 (zuvor v1.6.58). Der Build lief auf dem Entwicklungshost `alf@iris-server`. - **Enthalten:** Serverwechsel mit fremder Historie, Vault nur mit Dateien (iris/Iris#223), Wahl `both` in `resolve`, Aufräumen alter Git-Server-Token beim Anmelden und Bereitstellen (iris/Iris#230). - **Was Nutzer bekommen:** Neue Linux-Server-Instanzen und Aktualisierungen über die Registry holen diesen Stand. Die Mac-App und IrisRemote sind davon getrennt (nicht mit-veröffentlicht). - **Geprüft:** Build und Push aller sechs Images ohne Fehler, die Tags stehen in der Registry. Der Server lief schon vor dem Build mit demselben Quelltext auf iris-server (`/health` ok). - **Nicht geprüft:** ein frischer Start aus den veröffentlichten Images, eine Aktualisierung einer bestehenden Instanz über die Registry, der Serverwechsel gegen einen echten Forgejo mit großem Vault.
alf 2026-10-31 09:14:16 +00:00
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
No results found.
Labels
Clear labels
  
herkunft/alpha-feedback
Aus Rückmeldungen der Alpha-Tester

  
status
blockiert
 Wartet auf etwas anderes

  
status
zu-testen
 Gebaut, aber noch nicht im echten Einsatz geprüft

  
typ
bug
 Fehler

  
typ
docs
 Dokumentation

  
typ
enhancement
 Verbesserung einer vorhandenen Funktion

  
typ
feature
 Neue Funktion

  
typ
idea
 Idee, noch nicht entschieden

No labels
herkunft/alpha-feedback
status
blockiert
status
zu-testen
typ
bug
typ
docs
typ
enhancement
typ
feature
typ
idea
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
iris/Iris#230
No description provided.