This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

Glossar

Kurze Erklärungen zu Begriffen, die im Projekt (Code + Wiki) immer wieder auftauchen.

BEGIN IMMEDIATE (SQLite)

Eine SQLite-Transaktion, die sofort einen Schreib-Lock reserviert.
Damit werden parallele Schreibvorgänge serialisiert – wichtig, wenn mehrere Requests gleichzeitig eine Ressource “vergeben” wollen (z.B. Verkäufernummern).

• Im Projekt: atomare Nummernvergabe bei /registration/
• Siehe: Projekt-Landkarte, Performance & Optimierungen

PRG-Pattern (Post/Redirect/Get)

Nach einem erfolgreichen POST wird weitergeleitet (Redirect) auf eine GET-Seite.
Vorteile:

• verhindert “Formular erneut senden” bei Reload

• URL zeigt Status (?success=1, ?duplicate=1, …)

• Im Projekt: /registration/ redirectet nach /anmeldung/

CSRF (Cross-Site Request Forgery)

Ein Angriff, bei dem ein fremdes Formular/Script versucht, im Browser eines eingeloggten Users einen Request auszuführen.
Gegenmaßnahme: CSRF-Token, das nur der echte Browser-Session-Kontext kennt und bei jedem POST mitgeschickt wird.

• Im Projekt: CSRFService
• Siehe: Sicherheit

CSRF TTL (Token mit Ablaufzeit)

Ein CSRF-Token, das nicht nur “richtig/falsch”, sondern auch zeitlich begrenzt gültig ist (TTL = “time to live”).
Das reduziert Risiko bei sehr kurzlebigen Formularen (und passt gut zu “Formular nur X Minuten gültig”).

• Im Projekt: Registrierung nutzt TTL-Token (180s) + serverseitiges Formular-Timeout
• Siehe: Projekt-Landkarte

WAL (Write-Ahead Logging, SQLite)

Ein SQLite-Journaling-Modus, der parallele Zugriffe verbessert:

• Leser blockieren Schreiber weniger

• besseres Verhalten bei gleichzeitigen Requests

• Im Projekt: PRAGMA journal_mode = WAL

• Siehe: Performance & Optimierungen

PRAGMA (SQLite)

SQLite-spezifische Einstellungen, die das Verhalten/Performance beeinflussen (z.B. WAL, synchronous, cache_size).

• Im Projekt: gesetzt in Repository::CreatePDO()
• Siehe: Performance & Optimierungen

Token-Bucket (Rate-Limit)

Ein Rate-Limit-Verfahren: Es gibt einen “Eimer” mit Tokens, die mit einer Rate nachgefüllt werden.
1 Token = 1 erlaubte Aktion (hier: 1 Mail). Wenn keine Tokens da sind, wird gewartet.

Eigenschaften:

• hält ein Stundenlimit zuverlässig ein

• verteilt Last gleichmäßig

• erlaubt begrenzte Bursts (über die Bucket-Kapazität cap)

• Im Projekt: Mail-Queue Cron-Worker (mailMaxPerHour, Tokens persistiert in config)

• Siehe: Mail-Queue

“Claiming” (Jobs atomar übernehmen)

Bezeichnet das atomare “Übernehmen” von Jobs aus einer Queue:

• pending → sending

• inkl. Lock/Lease (locked_until)

• verhindert Doppelverarbeitung bei parallelen Workern

• Im Projekt: MailQueueRepository::claimNextJobs()

• Siehe: Mail-Queue

locked_until (Lease/Lock)

Zeitstempel bis wann ein Job als “in Bearbeitung” gilt.
Wenn ein Worker abstürzt, kann ein anderer Worker nach Ablauf des Leases den Job wieder übernehmen (“recover”).

• Im Projekt: mail_queue.locked_until
• Siehe: Mail-Queue

Backoff (Retry-Verzögerung)

Wenn etwas fehlschlägt, wird nicht sofort erneut probiert, sondern nach einer Verzögerung (z.B. 1 min, 5 min, 15 min, 60 min).
Das verhindert “Hammering” bei temporären Problemen.

• Im Projekt: Mail-Queue next_attempt_at + attempts-basierte Verzögerung
• Siehe: Mail-Queue

Idempotenz

Eine Operation ist idempotent, wenn sie mehrfach ausgeführt werden kann, ohne das Ergebnis zu “duplizieren”.
Beispiel: Enqueue eines Jobs sollte bei Wiederholung nicht zwei identische Jobs erzeugen.

• Im Projekt: Unique-Index (registration_number, mail_type) + INSERT OR IGNORE
• Siehe: Mail-Queue

.htaccess (Schutz von public/data/)

Apache-Konfigurationsdatei, die (hier) direkten HTTP-Zugriff auf DB/Logs blockt.

• Im Projekt: Build stellt public/data/.htaccess sicher
• Siehe: Projekt-Landkarte, Sicherheit