Fix #48: Optionaler Token-Ablauf mit Toggle und Ablaufprüfung - #49
Conversation
There was a problem hiding this comment.
Pull request overview
Erweitert das API-Token-Handling um ein optionales Ablaufdatum (expires_at) inkl. Backend-UI-Toggle und serverseitiger Berücksichtigung bei der Token-Autorisierung, um Tokens nach Ablauf automatisch nicht mehr zu akzeptieren (Fix #48).
Changes:
- DB-Schema um nullable
expires_atergänzt und Altwerte (0000-00-00 00:00:00/leer) aufNULLnormalisiert. - Token-Lookup/Autorisierung um Ablauf-Prüfung erweitert.
- Backend-Maske um „Ablauf aktiv“ + Datetime-Feld ergänzt, inkl. JS-Toggle (nur auf
api/tokengeladen).
Reviewed changes
Copilot reviewed 6 out of 6 changed files in this pull request and generated 5 comments.
Show a summary per file
| File | Description |
|---|---|
pages/token.php |
YForm-Formular um Ablauf-UI erweitert und expires_at nach Save normalisiert/gesetzt. |
lib/Token.php |
Token-Model um expires_at/Expiry-Checks ergänzt und Token-Lookup um Ablauf-Filter erweitert. |
install.php |
DB-Spalte expires_at angelegt und Altwerte auf NULL migriert. |
boot.php |
Lädt das neue Backend-JS nur auf der Token-Seite. |
assets/js/token-expiry.js |
Implementiert Toggle/Enable-Disable-Logik für das Ablaufdatum im Backend. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
Kleiner Nachtrag im selben PR: Statusanzeige auf der Token-Seite korrigiert.
|
Behebt drei Probleme, die den optionalen Ablauf praktisch unbrauchbar machten: 1. Ein im Backend angelegter Token war sofort abgelaufen. Das JS hakte "Ablauf aktiv" anhand der Datumsfelder an, und YForms datetime-Feld ist mit current_date=1 nie leer -- gespeichert wurde damit der Zeitpunkt des Formularaufrufs, der beim Absenden schon in der Vergangenheit lag. Der Default entscheidet jetzt serverseitig: beim Anlegen aus, beim Bearbeiten aktiv, wenn ein Datum gespeichert ist. Ohne aktive Checkbox schreibt die Seite NULL -- auch wenn das JS nicht lädt. 2. Der Jahresbereich des Feldes lief von 2006 bis zum laufenden Jahr, ein Ablaufdatum in der Zukunft war also nicht wählbar. Jetzt laufendes Jahr bis +10, vorbelegt mit "in einem Jahr" (modify_default). 3. Ein Datum ohne Jahr (z.B. 0000-03-15, wenn im Select kein Jahr gewählt wurde) ergab einen still unbrauchbaren Token. Normalisierung und Default-Ermittlung prüfen daher auf YEAR() < 1 statt nur auf 0000-00-00 00:00:00; install.php räumt solche Altbestände mit auf. Weitere Korrekturen: - Der Vergleich expires_at = '' entfaellt in getByToken(): er erzeugte pro Auth-Request eine MySQL-Warning 1292 und kann in einer nullable DATETIME-Spalte nicht vorkommen. - isExpired() vergleicht über die Datenbankzeit statt über time(). Bei abweichender PHP- und MySQL-Zeitzone urteilte die Methode anders als der Filter in getByToken(), der mit now() arbeitet. - Die Listenspalte trägt jetzt das Label "Ablaufdatum" statt des technischen Spaltennamens. - Toter Code in pages/token.php entfernt, dazu ein unbenutzter Import (php-cs-fixer). - README: Abschnitt zum Ablaufdatum.
|
Getestet gegen eine laufende Installation und um drei Korrekturen ergänzt (Commit 6670c0e), Der Ablauf funktionierte serverseitig korrekt (kein Ablauf → 200, Vergangenheit → 401, Zukunft → 200, exakt jetzt → 401), im Backend-Formular waren aber drei Dinge offen:
Kleinigkeiten dazu: der Der Nicht laufen konnte rexstan: es bricht in dieser Umgebung an einer PHP-8.5-Inkompatibilität in yform ab ( Dieser Text wurde durch eine KI erstellt. |
Bezug
Fixes #48
Was wurde umgesetzt?
expires_at, nullable) ergänzt.0000-00-00 00:00:00/ leer) werden aufNULLnormalisiert.Ablauf aktivCheckboxAblaufdatumals YForm-Datetimeboot.phpnur aufpage=api/token.expires_atzuverlässig aufNULLgesetzt.Wichtige Hinweise
Tests / Verifikation
redaxo/src/addons/api/lib/Token.php-> OKredaxo/src/addons/api/pages/token.php-> OK/api/search_it/capabilities) ->200401Ablauf aktivblendetAblaufdatumein/aus.expires_ataufNULL.