Bilder hinzugefügt von UI

03-Diplomarbeitsbuch-individueller-teil-Florian-Edlmayer.md

@@ -212,6 +212,8 @@ Der Umfang des Backups besteht aus zwei zentralen Komponenten:
    Damit wird eine vollständige Sicherung der Website ermöglicht, da bei einer reinen Datenbanksicherung wichtige Anwendungsdateien fehlen würden.
 
 ```mermaid
+%%| filename: flowchart-backup-system
+%%| fig-cap: Ablaufdiagramm des Backup-Systems
 graph TD
     %% Styling
     classDef startEnd fill:#f9f,stroke:#333,stroke-width:2px;
@@ -461,8 +463,8 @@ Zur Anmeldung auf der entwickelten Webplattform wurde eine Authentifizierung üb
 OAuth 2.0 basiert auf dem Prinzip der delegierten Autorisierung. Dabei erlaubt ein Benutzer einer Anwendung, bestimmte Informationen seines Kontos bei einem externen Dienst zu verwenden. Die eigentlichen Zugangsdaten – beispielsweise das LinkedIn-Passwort – verbleiben dabei ausschließlich beim Identitätsanbieter.
 
 Der grundlegende Ablauf einer OAuth-Authentifizierung ist in Abbildung X dargestellt. Dabei wird der Benutzer zunächst zur Login-Seite des externen Anbieters weitergeleitet. Nach erfolgreicher Anmeldung bestätigt der Benutzer, dass die Anwendung Zugriff auf bestimmte Profildaten erhalten darf.
-![OAuth-Authentifizierungsablauf](image.png)
-_Abbildung: Ablauf der OAuth-Authentifizierung (Erstellt mit ChatGPT)_
+
+![Ablauf der OAuth-Authentifizierung (Erstellt mit ChatGPT)](image.png)
 
 Die Abbildung zeigt den Ablauf der OAuth-Authentifizierung. Zunächst erfolgt die Weiterleitung zur LinkedIn-Anmeldeseite, anschließend wird ein Autorisierungscode (Authorization Code) an die Webanwendung zurückgegeben, welcher gegen einen Zugriffstoken (Access Token) ausgetauscht wird.
 
@@ -524,6 +526,8 @@ Der zentrale Zweck besteht darin, einen Anreiz für aktives Engagement im Verein
 Die Entwicklung erfolgte als eigenständiges Oqtane-Modul, wodurch eine nahtlose Integration in die bestehende Vereinswebsite gewährleistet wird. Das Modul nutzt dabei die vom Framework bereitgestellten Mechanismen für Authentifizierung, Autorisierung, Datenbankzugriff und Dateiverwaltung. Die Architektur folgt etablierten Entwurfsmustern wie dem Repository-Pattern, Dependency Injection und dem Service-Layer-Muster. Das kumulative Premium-System mit vollständigem Audit-Trail stellt sicher, dass alle Statusänderungen transparent und nachvollziehbar sind. Die modulare Struktur erlaubt eine einfache Erweiterung um zusätzliche Funktionen, ohne die bestehende Codebasis grundlegend verändern zu müssen.
 
 ```mermaid
+%%| filename: architecture-premium-module
+%%| fig-cap: Architektur des Premium-Bereich-Moduls
 graph TD
     subgraph Client [Client-Seite / WebAssembly]
         UI[Index.razor / Apply.razor] --> SvcC[IApplicationService]
@@ -575,6 +579,8 @@ public class EngineerApplication : ModelBase
 Die Klasse erbt von `ModelBase`, wodurch automatisch die Audit-Felder `CreatedBy`, `CreatedOn`, `ModifiedBy` und `ModifiedOn` zur Verfügung stehen. Das Feld `Status` bildet den aktuellen Workflow-Schritt ab und kann die Werte „Draft", „Submitted", „Approved" oder „Rejected" annehmen. Die hochgeladene PDF-Datei wird nicht direkt gespeichert, sondern über eine `FileId` im Oqtane-Dateisystem referenziert.
 
 ```mermaid
+%%| filename: classdiagram-engineer-application
+%%| fig-cap: Klassendiagramm der EngineerApplication-Entität
 classDiagram
     class EngineerApplication {
         +int ApplicationId
@@ -602,6 +608,8 @@ Der Lebenszyklus eines Antrags durchläuft mehrere Phasen. Der Benutzer beginnt
 
 Beim Absenden des Formulars erstellt die clientseitige Methode `SubmitApplication` ein neues `EngineerApplication`-Objekt und befüllt es mit den Formulardaten. Der Status wird dabei automatisch auf „Published" gesetzt, zusammen mit den Zeitstempeln für Einreichung und Genehmigung. Die Methode unterscheidet anhand der `ApplicationId`, ob ein neuer Antrag über den Service `AddApplicationAsync` erstellt oder ein bestehender über `UpdateApplicationAsync` aktualisiert werden soll. Falls keine Datei ausgewählt wurde, wird der Vorgang mit einer entsprechenden Fehlermeldung abgebrochen. Die Kommunikation mit dem Server erfolgt über den injizierten `ApplicationService`, der als HTTP-Client die Anfragen an den REST-Controller weiterleitet.
 
+![Formular zum Einreichen eines Ingenieur-Antrags](image-3.png)
+
 Serverseitig nimmt die Methode `AddApplicationAsync` im `ServerEngineerApplicationService` den Antrag entgegen. Dort wird zunächst geprüft, ob der Benutzer authentifiziert ist und die View-Berechtigung für das Modul besitzt. Die User-ID wird aus dem HTTP-Kontext extrahiert und dem Antrag zugewiesen, um sicherzustellen, dass kein Benutzer Anträge im Namen anderer erstellen kann. Anschließend wird der Antrag über das Repository in der Datenbank persistiert.
 
 Ein Administrator kann den Antrag entweder genehmigen oder ablehnen. Bei einer Genehmigung wird der Status auf „Approved" gesetzt und automatisch über den `PremiumService` eine 12-monatige Premium-Mitgliedschaft vergeben. Bei einer Ablehnung wechselt der Status auf „Rejected" und der Benutzer hat die Möglichkeit, einen überarbeiteten Antrag erneut einzureichen.
@@ -610,6 +618,8 @@ Ein Administrator kann den Antrag entweder genehmigen oder ablehnen. Bei einer G
 
 Die Antrags-Listenansicht bildet das zweite zentrale Feature. Premium-Mitglieder sehen alle genehmigten und veröffentlichten Anträge in einer übersichtlichen Kartenansicht. Jede Karte enthält den Titel, den Namen des Autors, die Kurzbeschreibung und das Veröffentlichungsdatum. Über integrierte Schaltflächen können die zugehörigen PDF-Dokumente direkt im Browser betrachtet oder heruntergeladen werden. Der PDF-Viewer wird als modales Fenster mit eingebettetem iFrame realisiert.
 
+![Ansicht der genehmigten Ingenieur-Anträge](image-4.png)
+
 Die serverseitige Methode `GetApplicationsAsync` steuert dabei die rollenbasierte Zugriffslogik und entscheidet, welche Anträge ein Benutzer sehen darf:
 
 ```C#
@@ -649,6 +659,8 @@ Administratoren erhalten alle Anträge zurück. Für andere Benutzer werden zun
 
 Die Mitgliedersuche ermöglicht Premium-Mitgliedern das gezielte Auffinden anderer registrierter Benutzer. Die clientseitige Blazor-Komponente `UserSearch.razor` stellt ein Eingabefeld bereit, über das der Benutzer seinen Suchbegriff eingibt. Bei jeder Suche wird der eingegebene Text an den `ServerUserContactService` auf dem Server übermittelt, der die eigentliche Suchlogik implementiert.
 
+![Mitgliedersuche und Kontaktfunktion für Premium-Mitglieder](image-5.png)
+
 Die serverseitige Methode `SearchUsersAsync` prüft zunächst, ob der Suchbegriff mindestens drei Zeichen umfasst, um übermäßig breite Abfragen zu vermeiden, und ob der anfragende Benutzer authentifiziert ist. Anschließend durchsucht sie die Benutzerdatenbank sowohl nach Anzeigenamen als auch nach Benutzernamen, wobei die Suche groß-/kleinschreibungsunabhängig erfolgt. Die Ergebnisse werden auf maximal 20 Treffer begrenzt.
 
 Besonders wichtig ist die Datenschutzfilterung: Anstatt die vollständigen `User`-Objekte aus der Datenbank zurückzugeben, erstellt die Methode neue, reduzierte Objekte, die nur die Felder `UserId`, `Username`, `DisplayName` und `PhotoFileId` enthalten. E-Mail-Adressen, Passwort-Hashes und andere sensible Daten werden dadurch serverseitig herausgefiltert, bevor die Ergebnisse an den Client gesendet werden. Dieser Ansatz folgt dem Prinzip der Datenminimierung — es werden nur die Informationen übertragen, die für die Anzeige der Suchergebnisse tatsächlich benötigt werden.
@@ -773,6 +785,8 @@ private bool IsUserPremium(System.Security.Claims.ClaimsPrincipal user)
 ```
 
 ```mermaid
+%%| filename: flowchart-premium-access
+%%| fig-cap: Zugriffsprüfung für Premium-Inhalte
 flowchart TD
     Req([Anfrage auf Premium-Inhalt]) --> Auth{User.Identity.IsAuthenticated?}