New: Token Lifetime

This commit is contained in:
2026-03-13 20:25:37 +00:00
committed by KoCoder
parent 978f5579fb
commit 4df7cc1cf7

View File

@@ -318,7 +318,12 @@ Lösungsansatz: Meetings und Besprechungen asynchron zueinander setzen.
- Entkoppelung von Meeting und Deadline: Meetings sollten der Synchronisation dienen, während die Abgabe von Arbeitspaketen kontinuierlich (Continuous Integration) erfolgen muss, um Lastspitzen (in der [Gitea Actions](#Continuous Integration) Pipeline) am Tag der Besprechung zu vermeiden. - Entkoppelung von Meeting und Deadline: Meetings sollten der Synchronisation dienen, während die Abgabe von Arbeitspaketen kontinuierlich (Continuous Integration) erfolgen muss, um Lastspitzen (in der [Gitea Actions](#Continuous Integration) Pipeline) am Tag der Besprechung zu vermeiden.
# Modules # Modules
## Mass Mailer
## Admin Modules
Eine C#-Solution, welche einige Module, welche für den Admineinsatz geschrieben worden sind beinhaltet. Dieses Modul besteht aus 3 Teilmodulen. Einem Modul für den Versand von Rundmails, eines für die Einstellung von der Token Lebenszeit bei Tokens, welche per EMail verschickt werden und eines, welches das Reporting-System übernimmt.
### Mass Mailing
Das Mass Mailer Modul ist eine administrative Erweiterung für den Alumnihub, die es dem Vorstand ermöglicht, personalisierte Rundschreiben an alle registrierten Mitglieder zu versenden. Da die Pflege der Mitgliederdaten direkt im CMS erfolgt, bietet dieses Modul eine nahtlose Integration ohne den Export von CSV-Listen in externe Newsletter-Tools. Das Mass Mailer Modul ist eine administrative Erweiterung für den Alumnihub, die es dem Vorstand ermöglicht, personalisierte Rundschreiben an alle registrierten Mitglieder zu versenden. Da die Pflege der Mitgliederdaten direkt im CMS erfolgt, bietet dieses Modul eine nahtlose Integration ohne den Export von CSV-Listen in externe Newsletter-Tools.
@@ -328,5 +333,19 @@ Für den tatsächlichen Versand der E-Mails nutzen wir den Cloud-Dienst Brevo. D
`Batch-Processing`: Mails werden nicht sofort ("Fire and Forget") versendet, sondern in eine Versandwarteschlange geschrieben. Nachdem schon die Notifications Infrastruktur, welche sich auch um den Mail versand kümmert, ins Framework eingebaut worden ist, nutzen wir diese geleich und `schedulen` unsere EMails. Immer 100 Mails alle 24 Stunden bis alle Ziele die Mails erhalten haben. Das Limit von 100 / Tag ist konservativ sehr niedrig angesetzt, damit funktionen wie Passwort Reset Mails nicht (leicht) dadurch beeinflusst werden können. `Batch-Processing`: Mails werden nicht sofort ("Fire and Forget") versendet, sondern in eine Versandwarteschlange geschrieben. Nachdem schon die Notifications Infrastruktur, welche sich auch um den Mail versand kümmert, ins Framework eingebaut worden ist, nutzen wir diese geleich und `schedulen` unsere EMails. Immer 100 Mails alle 24 Stunden bis alle Ziele die Mails erhalten haben. Das Limit von 100 / Tag ist konservativ sehr niedrig angesetzt, damit funktionen wie Passwort Reset Mails nicht (leicht) dadurch beeinflusst werden können.
### Token Lifetime
Das Token Lifetime Modul wurde geschrieben, um die Token-Lebenszeit konfigurierbar zu machen. Notwendig war das, um die Passwort Reset Links im initialen Mail versand länger gultig sein zu lassen. Durch das `Batch Processing` war es Möglich, dass eine Mail erst Tage nach erstellen des Links hinaus geschickt wird und bei einer Standard Ablaufdauer von 2 Tagen sind machne Links schon ungültig, bis sie den Mail Server erreichen. Ziel war es, die Änderung der Lebenszeit für Administratoren im User Interface im Admin Bereich möglich zu machen.
Es gibt 2 Möglichkeiten, wie man dieses Problem Lösen kann:
- `der Workarround`: Ein eigenes Modul, welches in seiner `Server/Startup.cs` die benötigten Werte korrekt setzt. Das hat den Vorteil, dass wir keine Änderungen im CMS selbst haben, sondern nur unsere eigene Erweiterung dafür schreiben. Andererseits könnte durch die undeterminischte Ladereihenfolge eine `race-condition` auftreten. Darüberhinaus haben wir keinen gleichzeitigen Zugriff auf appsettings.json und den IServiceProvider in dem wir die Konfiguration setzen müssen. => Nachdem wir in der Konfigurationsphase auch noch keinen Datenbankzugriff haben, können wir die Werte nicht aus der DB Laden, sondern müssen auf eine Text Datei zurückgreifen.
- `die saubere Lösung`: Eine Änderung im Kern von Oqtane. Also implementieren wir in unserem Fork von Oqtane die Konfigurationslogik für die Tokenlifetime. Hier könnte die Konfigurationslogik direkt in `OqtaneServiceCollectionExtensions.cs` hinzufügen, hier werden auch alle anderen Oqtane Spezifischen Configurationen gesetzt. Das hat den Vorteil, dass der Code aufgeräumter und sauberer ist und die `race-condition` verhindert werden kann. Der initiale Grund dagegen ist, dass wir ein weiteres Git Repository zum warten haben (den Fork vom Oqtane.Framework), welches jetzt nicht mehr mit Upstream Commit-gleich ist.
`Der Workarround` ist die Möglichkeit für die wir uns zuerst entschieden haben, allerdings haben wir uns im Nachhinein noch umentschlossen und wollen `die saubere Lösung` implementieren.
((Quellen einfügen: Configure Token for Email versand und Race Conditions beschreiben.))
### Reporting System
## Event Registration ## Event Registration
## Schwarzes Brett ## Schwarzes Brett