Elorette Homepage

Svelte-/Vite-Website. Lokale Entwicklung mit Node.js 24:

npm ci
npm run dev

Kontaktformular

Das Formular unter /nw sendet Name, E-Mail, Unternehmen (optional) und Nachricht per POST an /contact.php. Das PHP-Script liegt in src/public/contact.php; Vite kopiert es beim Build automatisch nach dist/contact.php. Der Empfänger und der feste Absender sind kontakt@eliashenrich.de, eine Kopie geht per CC an elihenrich@gmail.com; Reply-To enthält die geprüfte E-Mail-Adresse der anfragenden Person.

Die E-Mail enthält außerdem den Zeitpunkt (Europe/Berlin), die vom Webserver erkannte IP-Adresse (REMOTE_ADDR), den User-Agent mit Browser-/Betriebssystem- Angaben, bevorzugte Sprachen (Accept-Language) und die Formularseite (Referer). Browserangaben können fehlen oder manipuliert sein; fehlende Angaben werden als „Nicht übermittelt“ gekennzeichnet. Die Headerwerte werden einzeilig aufbereitet und auf jeweils 1.000 Zeichen begrenzt.

Bei einem Reverse-Proxy muss der Webserver die ursprüngliche Besucher-IP aus vertrauenswürdigen Proxy-Verbindungen übernehmen; andernfalls erscheint die Proxy-IP. Vom Browser gesetzte Weiterleitungsheader wertet das Script nicht aus.

Der Webserver muss PHP ab Version 7.2 ausführen und PHPs mail() muss für den Mailversand eingerichtet sein. Eine erfolgreiche Rückmeldung bedeutet, dass der Mailserver die Nachricht zum Versand angenommen hat; die Zustellung ins Postfach muss auf dem Produktionsserver geprüft werden.

Der Vite-Entwicklungsserver führt kein PHP aus. Für einen lokalen Test nach npm run build zusätzlich php -S 127.0.0.1:8080 -t dist starten und http://127.0.0.1:8080/nw öffnen. Auch lokal benötigt der tatsächliche Versand eine konfigurierte Mailanbindung.

Forgejo Actions

Der Workflow deploy.yml ersetzt die bisherige Bitbucket-Pipeline. Jeder Push auf main baut die Website und veröffentlicht sie auf dem Produktionsserver. Über Actions → Build and deploy → Run workflow kann der Workflow auch manuell für main gestartet werden. Auf anderen Branches erfolgt kein Deployment.

Die Ausdrücke verwenden den von Forgejo unterstützten Kompatibilitätskontext github.*, damit auch Runner-/Schema-Versionen ohne Unterstützung für forgejo.* den Workflow validieren können. Diese Werte beziehen sich auf die Forgejo-Instanz und erfordern keine Verbindung zu GitHub.

Einrichtung in Forgejo

1. In den Repository-Einstellungen Actions aktivieren.
2. Einen Docker-Runner mit dem Label docker bereitstellen. Der Job verwendet das Image node:24-bookworm und benötigt ausgehenden Zugriff auf die Forgejo-Instanz, data.forgejo.org, Docker Hub, npm, Debian-Paketquellen und den Produktionsserver. Das Container-Image wird als Root ausgeführt, damit der SSH-Client installiert werden kann.
3. Unter Einstellungen → Actions → Variables die Serverkonfiguration und unter Einstellungen → Actions → Secrets den privaten Schlüssel anlegen. Bitbucket-Deployment-Variablen, SSH-Schlüssel und bekannte Hosts werden beim Repository-Import nicht automatisch übernommen.

Name	Typ	Inhalt
PROD_SERVER_SSH	Variable	SSH-Ziel als benutzer@hostname oder benutzer@IPv4.
PROD_SERVER_ROOT_DIR	Variable	Absoluter Pfad zum Website-Verzeichnis, z. B. /var/www/elorette; ohne Leerzeichen, nur Buchstaben, Ziffern, _, ., / und -.
PROD_SERVER_SSH_PORT	Variable	Optionaler SSH-Port; Standard: 22.
PROD_SSH_KNOWN_HOSTS	Variable oder Secret	Verifizierte known_hosts-Zeile(n) des Produktionsservers.
PROD_SSH_PRIVATE_KEY	Secret	Vollständiger privater Deployment-Schlüssel, einschließlich Kopf-/Fußzeilen und Zeilenumbrüchen, ohne Passphrase. Der öffentliche Schlüssel muss beim Zielbenutzer in authorized_keys liegen.

Für die Serverkonfiguration und known_hosts werden auch bestehende Secrets unter denselben Namen unterstützt. Nicht leere Variablen haben Vorrang. Der private Schlüssel wird ausschließlich aus einem Secret gelesen.

Den Hostschlüssel über einen vertrauenswürdigen Zugang mit dem Server abgleichen. Mit ssh-keyscan -H hostname lässt sich eine known_hosts-Zeile ermitteln; der Scan allein bestätigt die Identität des Servers nicht. Bei einem anderen Port ssh-keyscan -p PORT -H hostname verwenden. Die Pipeline prüft den Hostschlüssel strikt gegen die hinterlegten known_hosts-Einträge.

Build und Veröffentlichung

Der Build verwendet npm ci mit der vorhandenen package-lock.json und npm run build. Anschließend werden wie bisher die Bilder aus src/assets/images und die Apache-Konfiguration .htaccess nach dist kopiert.

Der Produktionsserver benötigt Bash, tar und GNU mv (Linux). Der SSH-Benutzer braucht Schreibrechte im Website-Verzeichnis; der Webserver muss den Symlink live als DocumentRoot verwenden und .htaccess/mod_rewrite unterstützen. Das Verzeichnis releases wird bei Bedarf angelegt.

Jeder Lauf erhält ein eigenes Verzeichnis releases/release_forgejo_<run_id>_<run_attempt>/dist und ein gleichnamiges .tar.gz-Archiv. Das Präfix vermeidet Kollisionen mit alten Bitbucket-Releases; die Laufversuchsnummer erlaubt erneute Ausführungen. Erst nach erfolgreichem Upload, Entpacken und Prüfen der Dateien wird live atomar auf das neue Release umgestellt. Forgejo führt Produktionsläufe über eine gemeinsame Concurrency-Gruppe nacheinander aus und bricht laufende Deployments bei neuen Pushes nicht ab. Alte Releases und Archive bleiben für ein manuelles Rollback erhalten.

Die Workflow-Syntax und Runner-Zuordnung folgen der Forgejo-Actions-Referenz.