taarly/PHP_AdminTool_Projekt
3
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Page: Architektur-und-Design
Pages
Anforderungen Architektur-und-Design Coding-Guidelines Fehlerbehandlung-und-Logging Gitea-Workflow Home Implementierungshandbuch-IIS-PHP-AD Logging-Service Projektstruktur-und-Best-Practices
1 Architektur-und-Design
blaerf edited this page 2025-11-29 13:59:46 +01:00
Unescape Escape
Table of Contents
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.

Architektur und Design

Ziel dieses Dokuments

Dieses Dokument beschreibt die interne Architektur der Webanwendung PHP Admin Tool.
Es soll Entwickler einen schnellen Überblick geben, wie die einzelnen Komponenten zusammenspielen und wo neue Funktionalität ergänzt werden kann.

Übersicht

Die Anwendung folgt einem mehrschichtigen Aufbau:

  • Front-Controller (public/index.php)
  • Controller-Schicht (app/Controllers)
  • Service-Schicht (app/Services/...)
  • View-Schicht (public/views/...)
  • Infrastruktur (IIS, PHP, PowerShell, AD, SNMP) – ausführlich im Implementierungshandbuch beschrieben

Request-Flow

  1. Eine HTTP-Anfrage trifft auf public/index.php.
  2. Der Front-Controller:
    • initialisiert den Autoloader,
    • lädt die Konfiguration aus config/config.php,
    • startet die Session (für Login-Zustand),
    • instanziiert die Controller.
  3. Über den GET-Parameter route wird entschieden, welcher Controller und welche Methode ausgeführt wird (z. B. login, dashboard, users).
  4. Der Controller ruft bei Bedarf Services auf (z. B. LDAP-Service, SNMP-Service) und erstellt ein View-Result-Array.
  5. Das View-Result-Array wird an das zentrale Layout (public/views/layout.php) übergeben.
  6. Das Layout bindet die entsprechenden View-Templates ein (z. B. login.php, dashboard.php, users.php) und rendert HTML.

Controller-Schicht

  • Liegt im Namespace App\Controllers.

  • Jeder Controller ist für einen logisch abgegrenzten Bereich zuständig:

    • AuthController: Login, Logout, Session-Verwaltung
    • DashboardController: Anzeige von Serverstatus und Monitoring-Daten
    • UserManagementController: Anzeige von Benutzern und Gruppen (LDAP-Abfragen)

  • Controller geben kein HTML aus, sondern liefern strukturierte Arrays an die View-Schicht.

Service-Schicht

  • Liegt im Namespace App\Services\....

  • Kapselt technische Details und externe Systeme:

    • App\Services\Ldap\LdapConnectionHelper: Aufbau der LDAP-Verbindung (ohne Bind).
    • App\Services\Ldap\LdapDirectoryService: Suchen von Benutzern und Gruppen im AD.
    • App\Services\Snmp\SnmpServerStatusService: Auslesen von Serverkennzahlen per SNMP.
    • App\Services\Powershell\... (geplant): Ausführung von PowerShell-Skripten.

  • Controller sprechen nur über diese Services mit LDAP, SNMP und PowerShell – direkte Zugriffe aus Views sind nicht erlaubt.

View-Schicht

  • Liegt unter public/views/:

    • layout.php enthält die zentrale Funktion renderLayout().
    • Unter public/views/partials/ liegen head.php, sidebar.php, topbar.php, footer.php, scripts.php.
    • Inhaltliche Seiten wie login.php, dashboard.php, users.php stellen nur den jeweiligen Content innerhalb des Layouts dar.

  • Die Views bekommen vom Controller vordefinierte Variablen (z. B. $serverStatus, $users, $groups) und sind für:

    • Ausgabeformatierung
    • Tabellen, Formulare, UI-Elemente (auf Basis SB Admin 2)

    zuständig.

Sicherheitsaspekte (kurz)

  • Zugang zur Anwendung nur für AD-Administrator (Login über LDAP/LDAPS).
  • Nach erfolgreichem Login wird der Benutzerstatus in der Session gespeichert.
  • Geschützte Routen prüfen den Login-Zustand, bevor Inhalte geladen werden.
  • Technische Fehlerdetails (z. B. LDAP-Fehler, SNMP-Fehler) werden nicht direkt im Browser angezeigt, sondern sollen über das Logging (siehe Seite „Fehlerbehandlung und Logging“) behandelt werden.

Erweiterbarkeit

Neue Funktionen werden nach folgendem Muster ergänzt:

  1. Neue Route im Front-Controller definieren.
  2. Neue Methode im zuständigen Controller anlegen.
  3. Gegebenenfalls neue Service-Klasse anlegen oder bestehende erweitern.
  4. Neues View-Template unter public/views/ anlegen.
  5. Falls nötig, Menüeintrag in der Sidebar hinzufügen.

Dieses Muster stellt sicher, dass die Architektur konsistent bleibt und Verantwortlichkeiten klar getrennt sind.