M_Viper/deskhub
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 1 Wiki Activity

README.md aktualisiert

Browse Source
This commit is contained in:
M_Viper
2026-10-16 19:24:50 +00:00
parent 55a1807757
commit 845abfa9d9
1 changed files with 16 additions and 8 deletions
Download Patch File Download Diff File Expand all files Collapse all files
README.md
+16 -8
View File
@@ -204,7 +204,7 @@ Im Menü gibt es den Punkt **„Adminportal“**. Er ist für echte Admins immer
### Kundenportal-Design (Themes)
Unter **Einstellungen → Design** lassen sich mehrere Themes als ZIP-Datei hochladen, aktivieren und löschen. Ein aktiviertes Theme gilt für das ganze Kundenportal. Mit **„Standarddesign nutzen“** wird es wieder deaktiviert. Der Anzeigename wird aus dem Dateinamen der ZIP übernommen; lädt man ein Theme mit gleichem Namen erneut hoch, ersetzt es die vorhandene Version. Fertige Themes liegen im Ordner `theme-packages/`. Außerdem könnt ihr Themes direkt aus dem Katalog der Plugin-Webseite installieren: Auf derselben Seite erscheint unter **„Themes aus dem Katalog“** das Angebot automatisch. Prüfsumme und Signatur (mit dem unter Plugins hinterlegten Herausgeber-Schlüssel) werden vor der Installation geprüft; aktiviert wird das Theme erst, wenn ihr es selbst aktiviert.
Unter **Einstellungen → Design** lassen sich mehrere Themes als ZIP-Datei hochladen, aktivieren und löschen. Ein aktiviertes Theme gilt für das ganze Kundenportal. Mit **„Standarddesign nutzen“** wird es wieder deaktiviert. Der Anzeigename wird aus dem Dateinamen der ZIP übernommen; lädt man ein Theme mit gleichem Namen erneut hoch, ersetzt es die vorhandene Version. Fertige Themes (darunter die Saison-Themes **Halloween Nacht** und **Weihnachten Winter**) liegen als ZIP im Ordner `theme/` des Projekts. Außerdem könnt ihr Themes direkt aus dem Katalog der Plugin-Webseite installieren: Auf derselben Seite erscheint unter **„Themes aus dem Katalog“** das Angebot automatisch. Prüfsumme und Signatur (mit dem unter Plugins hinterlegten Herausgeber-Schlüssel) werden vor der Installation geprüft; aktiviert wird das Theme erst, wenn ihr es selbst aktiviert.
---
@@ -388,6 +388,14 @@ Adminportal → **System-Update** hat zwei Teile:
**Datenbank aktualisieren:** Die Karte „Datenbank“ zeigt, ob die Datenbank zum installierten Programm passt. Wenn nicht, erscheint dort und für Admins oben auf jeder Seite ein Hinweis. Der Knopf **„Datenbank aktualisieren“** erstellt zuerst ein Backup und spielt dann alle fehlenden Änderungen ein. Das ist der richtige Weg, wenn ihr Dateien per FTP hochgeladen habt. Scheitert das Backup, wird die Datenbank nicht angefasst.
**Signierte Updates:** Ist in DeskHub ein Herausgeber-Schlüssel eingebaut (`includes/catalog_defaults.php`), installiert das System-Update nur Releases, die mit diesem Schlüssel signiert sind. Ein manipuliertes Paket oder ein Release ohne Signatur wird abgelehnt und im Admin-Protokoll vermerkt. Ein manuell hochgeladenes ZIP wird nicht geprüft, ladet nur Pakete aus vertrauenswürdiger Quelle hoch. Es steckt kein Zugangstoken mehr im Programmcode: Die Releases werden öffentlich gelesen. Ist das Repository privat, tragt ihr in `config/config.php` ein Lese-Token ein: `'update' => ['token' => '…']` (nur Leserecht vergeben).
**Release veröffentlichen (für den Herausgeber):**
1. ZIP des Projekts als `deskhub-<version>.zip` packen (ohne `config/config.php`, Datenbank, Backups, Uploads, `plugins/`, `node_modules`).
2. Signieren: `php tools/release-sign.php deskhub-1.0.7.zip herausgeber-privat.pem 1.0.7` (derselbe private Schlüssel wie für Plugins und Themes). Das erzeugt `deskhub-1.0.7.zip.sig`.
3. Im Gitea-Release **beide Dateien als Anhänge** hochladen, mit genau diesen Namen.
Nach jedem Update: Browser-Cache leeren (Strg + F5).
---
@@ -470,7 +478,7 @@ Katalog und Schlüssel sind **fest in DeskHub eingebaut** (`includes/catalog_def
### Mitgeliefertes Plugin: Tagesbericht per E-Mail
Unter `docs/plugins/tagesbericht-1.0.0.zip` liegt ein fertiges Plugin. Es schickt Mitarbeitern jeden Morgen eine Übersicht: offene, unzugewiesene, überfällige und eigene Tickets, Zugänge und Erledigungen der letzten 24 Stunden sowie die fünf ältesten offenen Tickets. Jeder sieht nur Tickets seiner Abteilungen.
Unter `Plugins/plugins/tagesbericht-1.0.0.zip` (im Projektordner neben `DeskHub-Webseite/`) liegt ein fertiges Plugin. Es schickt Mitarbeitern jeden Morgen eine Übersicht: offene, unzugewiesene, überfällige und eigene Tickets, Zugänge und Erledigungen der letzten 24 Stunden sowie die fünf ältesten offenen Tickets. Jeder sieht nur Tickets seiner Abteilungen.
Nach Installation und Aktivierung findet ihr im Menü den Punkt **„Tagesbericht“**: Dort schaltet ihr den Versand ein, legt Uhrzeit, Werktage und Empfänger fest und könnt einen **Testbericht** an euch schicken. Voraussetzung ist der eingerichtete E-Mail-Versand.
@@ -478,7 +486,7 @@ Nach Installation und Aktivierung findet ihr im Menü den Punkt **„Tagesberich
## Plugins entwickeln
Dieser Abschnitt richtet sich an Entwickler. Ein vollständiges, lauffähiges Beispiel liegt in `docs/plugin-beispiel/`, ein praxisnahes in `docs/plugins/tagesbericht/`.
Dieser Abschnitt richtet sich an Entwickler. Ein vollständiges, lauffähiges Beispiel liegt in `Plugins/plugin-beispiel/`, ein praxisnahes in `Plugins/plugins/tagesbericht/` (jeweils im Projektordner neben `DeskHub-Webseite/`).
### Aufbau
@@ -621,7 +629,7 @@ plugin_register_menu('Ticket-Zähler', 'uebersicht');
### Signieren und veröffentlichen
Wer Plugins oder Themes verteilt, signiert sie mit einem eigenen Schlüsselpaar (RSA, SHA-256). Das Werkzeug dafür liegt im Entwickler-Paket unter `tools/plugin-sign.php`:
Wer Plugins oder Themes verteilt, signiert sie mit einem eigenen Schlüsselpaar (RSA, SHA-256). Das Werkzeug dafür liegt im Entwickler-Paket unter `tools/plugin-sign.php` (für DeskHub-Releases selbst gibt es `tools/release-sign.php`, siehe [System-Update](#system-update-und-datenbank-update)):
```bash
php tools/plugin-sign.php keygen ./schluessel # einmalig: privater + öffentlicher Schlüssel
@@ -648,9 +656,9 @@ Für Themes heißt die Liste `themes` (ohne `requires` und `permissions`). Adres
## Plugin- und Theme-Webseite
Im Ordner `plugin-webseite/` liegt eine fertige, eigenständige Webseite, von der DeskHub-Installationen Plugins und Themes laden. Sie läuft auf eigenem Webspace (PHP 8.1, SQLite) und braucht kein DeskHub. Sie bietet den Katalog für DeskHub und eine geschützte Verwaltung zum Veröffentlichen mit allen Versionen, Prüfsummen und Signaturstatus. Es gibt keine öffentliche Übersichtsseite. Hochgeladene Pakete werden geprüft (Dateitypen, Pfade, `plugin.json`, Berechtigungen) und automatisch mit eurem Schlüssel signiert. Einrichtung in zwei Minuten per `php einrichten.php`, Details in `plugin-webseite/README.md`.
Im Projektordner `plugin-webseite/` (neben `DeskHub-Webseite/`, nicht Teil der DeskHub-Installation auf Kunden-Servern) liegt eine fertige, eigenständige Webseite, von der DeskHub-Installationen Plugins und Themes laden. Sie läuft auf eigenem Webspace (PHP 8.1, SQLite) und braucht kein DeskHub. Sie bietet den Katalog für DeskHub und eine geschützte Verwaltung zum Veröffentlichen mit allen Versionen, Prüfsummen und Signaturstatus. Es gibt keine öffentliche Übersichtsseite. Hochgeladene Pakete werden geprüft (Dateitypen, Pfade, `plugin.json`, Berechtigungen) und automatisch mit eurem Schlüssel signiert. Einrichtung in zwei Minuten per `php einrichten.php`, Details in `plugin-webseite/README.md`.
**Geprüfte Plugins für eure Kunden:** `php einrichten.php` (und in der Verwaltung der Bereich „Einstellungen für DeskHub“) gibt die drei Werte aus, die in `includes/catalog_defaults.php` von DeskHub eingetragen werden: Katalog-Adresse für Plugins, Katalog-Adresse für Themes und euren öffentlichen Schlüssel. Tragt sie vor dem Bauen eines Releases ein. Alle Installationen mit diesem Release laden dann nur Plugins, die ihr auf der Webseite veröffentlicht, also geprüft und signiert habt. Die Datei wird bei System-Updates durch die des Releases ersetzt, Kunden können die Vorgabe also nicht versehentlich verlieren. Dieser Ordner wird bei System-Updates nicht auf Kunden-Installationen kopiert.
**Geprüfte Plugins für eure Kunden:** `php einrichten.php` (und in der Verwaltung der Bereich „Einstellungen für DeskHub“) gibt die drei Werte aus, die in `includes/catalog_defaults.php` von DeskHub eingetragen werden: Katalog-Adresse für Plugins, Katalog-Adresse für Themes und euren öffentlichen Schlüssel. Tragt sie vor dem Bauen eines Releases ein. Alle Installationen mit diesem Release laden dann nur Plugins, die ihr auf der Webseite veröffentlicht, also geprüft und signiert habt. Die Datei wird bei System-Updates durch die des Releases ersetzt, Kunden können die Vorgabe also nicht versehentlich verlieren. Der Ordner `plugin-webseite/` gehört nicht zur DeskHub-Installation und wird nie auf Kunden-Server kopiert.
**Zugangsschutz des Katalogs:** `docker-build.sh` / `docker-build.ps1` erzeugen beim ersten Bauen einen Zugangsschlüssel (`schluessel/katalog-zugangsschluessel.txt`) und geben ihn am Ende aus. Tragt ihn in `includes/catalog_defaults.php` als `access_key` ein. Ohne diesen Schlüssel liefern Katalog, Downloads, Vorschaubilder und `publisher-key.php` nur `401`. `health.php` bleibt offen (Docker-Healthcheck). Nach dem Bauen: Image auf dem Server austauschen und ein DeskHub-Release mit dem eingetragenen Schlüssel veröffentlichen.
@@ -835,7 +843,7 @@ ok = hmac.compare_digest(expected, request.headers.get("X-DeskHub-Signature", ""
```nginx
# Interne Ordner und Dateien nie ausliefern
location ~ ^/(config|database|includes|cron|backups|tests|tools|docs|desktop|mobile|theme-packages|vorschaubilder|plugin-webseite|app_downloads|\.git|\.gitea|\.github)(/|$) { return 404; }
location ~ ^/(config|database|includes|cron|backups|tests|tools|docs|app_downloads|\.git|\.gitea|\.github)(/|$) { return 404; }
location ~ ^/plugins/.+\.(php|sql|json|md|txt|log)$ { return 404; }
location ~ ^/(version\.php|offen\.txt|install\.sh|install_windows\.bat)$ { return 404; }
location ~* \.(sqlite3?|db|sql|log|bak|old|md|sh|bat|ps1|pem|key|env|ini|lock)$ { return 404; }
@@ -883,7 +891,7 @@ Außerdem erstellt DeskHub automatisch ein Backup vor jedem System-Update, jedem
## Automatische Tests (CI)
`php tests/run_all.php` führt alle PHP-Tests nacheinander aus (Exit-Code 1 bei Fehlern); mit Argument nur passende Tests, z. B. `php tests/run_all.php plugin`. Die Workflow-Datei `.gitea/workflows/tests.yml` startet bei jedem Push, jeder Pull-Request und nachts um 03:17 UTC: PHP 8.2 (Syntax und alle Tests), PHP 8.4 (nur Warnung), Windows-App-Oberflächentests (`npm test` unter xvfb), Android-Tests (`./gradlew testDebugUnitTest`) und der Bau des Docker-Images der Plugin-Webseite samt Zugangsschutz-Prüfung. Für GitHub die Datei nach `.github/workflows/` kopieren. Der Runner braucht für den Docker-Job Docker, für den Android-Job das Android-SDK.
Im Ordner `DeskHub-Webseite/` führt `php tests/run_all.php` alle PHP-Tests nacheinander aus (Exit-Code 1 bei Fehlern); mit Argument nur passende Tests, z. B. `php tests/run_all.php plugin`. Die Tests für Plugin-Webseite und Plugin-Quellen suchen ihre Ordner neben `DeskHub-Webseite/` (`plugin-webseite/`, `Plugins/`); abweichende Orte lassen sich mit `DESKHUB_WEBSITE_DIR` und `DESKHUB_PLUGIN_SRC` angeben, fehlt ein Ordner, werden diese Tests übersprungen. Die Workflow-Datei `.gitea/workflows/tests.yml` im Projektordner startet bei jedem Push, jeder Pull-Request und nachts um 03:17 UTC: PHP 8.2 (Syntax und alle Tests), PHP 8.4 (nur Warnung), Windows-App-Oberflächentests (`npm test` unter xvfb), Android-Tests (`./gradlew testDebugUnitTest`) und der Bau des Docker-Images der Plugin-Webseite samt Zugangsschutz-Prüfung. Für GitHub die Datei nach `.github/workflows/` kopieren (die Pfade im Workflow gelten für diese Ordnerstruktur). Der Runner braucht für den Docker-Job Docker, für den Android-Job das Android-SDK.
---