chore: Docs umstrukturiert, Client-Updates, Scripts nach scripts/
This commit is contained in:
51
docs/deployment/DEPLOYMENT_INSTRUCTIONS.md
Normal file
51
docs/deployment/DEPLOYMENT_INSTRUCTIONS.md
Normal file
@@ -0,0 +1,51 @@
|
||||
# Deployment-Anleitung
|
||||
|
||||
## Status
|
||||
✅ **Build erfolgreich erstellt** - `client/dist` ist bereit für Deployment
|
||||
|
||||
## Git Commit & Push
|
||||
Da Git nicht automatisch gefunden werden kann, führe bitte diese Befehle manuell aus:
|
||||
|
||||
```bash
|
||||
cd c:\Users\User\Documents\GitHub\ANDJJJJJJ
|
||||
git add .
|
||||
git commit -m "fix: TypeScript errors & build fixes for Control Panel Redesign
|
||||
|
||||
- Fix unused imports (Trash, Filter, Bell, CategoryAdvanced)
|
||||
- Fix undefined checks for cleanup settings
|
||||
- Fix cleanupPreview undefined checks
|
||||
- Fix useTheme unused parameter
|
||||
- Fix companyLabels type safety
|
||||
- Build erfolgreich durchgeführt"
|
||||
git push
|
||||
```
|
||||
|
||||
## Deployment des Builds
|
||||
|
||||
### Option 1: Manuelles Upload
|
||||
1. Öffne den Ordner: `c:\Users\User\Documents\GitHub\ANDJJJJJJ\client\dist`
|
||||
2. Kopiere alle Dateien aus diesem Ordner
|
||||
3. Lade sie auf deinen Web-Server hoch (z.B. via FTP/SFTP zu `emailsorter.webklar.com`)
|
||||
|
||||
### Option 2: SSH/SCP (falls verfügbar)
|
||||
```bash
|
||||
scp -r client/dist/* user@webklar.com:/path/to/webserver/emailsorter/
|
||||
```
|
||||
|
||||
### Option 3: GitHub Actions / CI/CD
|
||||
Falls du CI/CD eingerichtet hast, sollte der Push automatisch deployen.
|
||||
|
||||
## Nach dem Deployment
|
||||
1. Leere den Browser-Cache (Strg+Shift+R)
|
||||
2. Prüfe die Website: https://emailsorter.webklar.com
|
||||
3. Teste die neuen Features:
|
||||
- Control Panel mit Card-Layout
|
||||
- Side Panels für Category Configuration
|
||||
- Cleanup Tab mit Slidern
|
||||
- Labels Tab mit Tabelle
|
||||
- Dark Mode Verbesserungen
|
||||
|
||||
## Wichtige Hinweise
|
||||
- Stelle sicher, dass `.env.production` die richtigen Production-URLs hat
|
||||
- Backend-Server muss laufen
|
||||
- Appwrite CORS muss für `https://emailsorter.webklar.com` konfiguriert sein
|
||||
219
docs/deployment/GITEA_WEBHOOK_SETUP.md
Normal file
219
docs/deployment/GITEA_WEBHOOK_SETUP.md
Normal file
@@ -0,0 +1,219 @@
|
||||
# Gitea Webhook Setup - Automatisches Deployment
|
||||
|
||||
Diese Anleitung erklärt, wie du einen Gitea-Webhook einrichtest, um automatisch zu deployen, wenn Code gepusht wird.
|
||||
|
||||
## Übersicht
|
||||
|
||||
Der Webhook funktioniert folgendermaßen:
|
||||
1. **Push auf Gitea** → Gitea sendet Webhook-Event an deinen Server
|
||||
2. **Webhook-Handler** empfängt das Event und verifiziert die Signatur
|
||||
3. **Deployment-Skript** wird ausgeführt:
|
||||
- Git Pull (falls auf Server)
|
||||
- Frontend Build (`npm run build`)
|
||||
- Upload auf Production-Server (via SCP/SSH)
|
||||
- Backend Neustart (optional, via PM2)
|
||||
|
||||
## Voraussetzungen
|
||||
|
||||
- ✅ Gitea-Repository mit deinem Code
|
||||
- ✅ Production-Server mit SSH-Zugriff
|
||||
- ✅ Node.js auf dem Server installiert
|
||||
- ✅ PM2 installiert (optional, für Backend-Neustart)
|
||||
|
||||
## Schritt 1: Webhook-Secret generieren
|
||||
|
||||
Generiere ein sicheres Secret für die Webhook-Signatur-Verification:
|
||||
|
||||
```bash
|
||||
# Generiere ein zufälliges Secret (32 Zeichen)
|
||||
node -e "console.log(require('crypto').randomBytes(16).toString('hex'))"
|
||||
```
|
||||
|
||||
**Wichtig:** Speichere dieses Secret sicher - du brauchst es in Schritt 3 und 4.
|
||||
|
||||
## Schritt 2: Environment Variables konfigurieren
|
||||
|
||||
Füge folgende Variablen zu deiner `server/.env` Datei hinzu:
|
||||
|
||||
```bash
|
||||
# Gitea Webhook Secret (aus Schritt 1)
|
||||
GITEA_WEBHOOK_SECRET=dein_generiertes_secret_hier
|
||||
|
||||
# Optional: Authorization Header Token
|
||||
GITEA_WEBHOOK_AUTH_TOKEN=dein_auth_token_hier
|
||||
|
||||
# Server-Deployment (optional, nur wenn automatischer Upload gewünscht)
|
||||
DEPLOY_SERVER_HOST=91.99.156.85
|
||||
DEPLOY_SERVER_USER=root
|
||||
DEPLOY_SERVER_PATH=/var/www/emailsorter
|
||||
DEPLOY_SSH_KEY=/path/to/ssh/private/key # Optional, falls SSH-Key benötigt wird
|
||||
DEPLOY_FRONTEND_PATH=/var/www/emailsorter/client/dist
|
||||
DEPLOY_BACKEND_PATH=/var/www/emailsorter/server
|
||||
|
||||
# PM2 für Backend-Neustart (optional)
|
||||
USE_PM2=true
|
||||
```
|
||||
|
||||
## Schritt 3: Webhook in Gitea konfigurieren
|
||||
|
||||
1. **Öffne dein Repository** in Gitea
|
||||
2. Gehe zu **Settings** → **Webhooks**
|
||||
3. Klicke auf **Add Webhook** → **Gitea**
|
||||
4. Fülle die Felder aus:
|
||||
|
||||
- **Target URL:**
|
||||
```
|
||||
https://emailsorter.webklar.com/api/webhook/gitea
|
||||
```
|
||||
(Ersetze mit deiner tatsächlichen Domain)
|
||||
|
||||
- **HTTP Method:** `POST`
|
||||
|
||||
- **Post Content Type:** `application/json`
|
||||
|
||||
- **Secret:**
|
||||
```
|
||||
dein_generiertes_secret_hier
|
||||
```
|
||||
(Das gleiche Secret wie in Schritt 1)
|
||||
|
||||
- **Authorization Header:** (Optional)
|
||||
```
|
||||
Bearer dein_auth_token_hier
|
||||
```
|
||||
|
||||
- **Trigger On:**
|
||||
- ✅ **Push Events** (wichtig!)
|
||||
- Optional: **Create**, **Delete** (falls gewünscht)
|
||||
|
||||
- **Branch Filter:** `main` oder `master` (je nach deinem Standard-Branch)
|
||||
|
||||
5. Klicke auf **Add Webhook**
|
||||
|
||||
## Schritt 4: Webhook testen
|
||||
|
||||
### Option A: Test über Gitea UI
|
||||
|
||||
1. Gehe zurück zu **Settings** → **Webhooks**
|
||||
2. Klicke auf deinen Webhook
|
||||
3. Klicke auf **Test Delivery** → **Push Events**
|
||||
4. Prüfe die Antwort:
|
||||
- ✅ **Status 202** = Webhook empfangen, Deployment gestartet
|
||||
- ❌ **Status 401** = Secret falsch
|
||||
- ❌ **Status 500** = Server-Fehler (prüfe Server-Logs)
|
||||
|
||||
### Option B: Test über Git Push
|
||||
|
||||
1. Mache eine kleine Änderung (z.B. Kommentar in einer Datei)
|
||||
2. Committe und pushe:
|
||||
```bash
|
||||
git add .
|
||||
git commit -m "test: Webhook test"
|
||||
git push
|
||||
```
|
||||
3. Prüfe die Server-Logs:
|
||||
```bash
|
||||
# Auf dem Server
|
||||
pm2 logs emailsorter-backend
|
||||
# Oder
|
||||
tail -f /var/log/emailsorter/webhook.log
|
||||
```
|
||||
4. Du solltest sehen:
|
||||
```
|
||||
📥 Gitea Webhook empfangen
|
||||
🚀 Starte Deployment...
|
||||
📦 Baue Frontend...
|
||||
✅ Deployment erfolgreich abgeschlossen
|
||||
```
|
||||
|
||||
## Schritt 5: Deployment-Logs prüfen
|
||||
|
||||
Die Webhook-Handler loggen alle Schritte. Prüfe die Logs:
|
||||
|
||||
```bash
|
||||
# PM2 Logs
|
||||
pm2 logs emailsorter-backend
|
||||
|
||||
# Oder direkt im Server
|
||||
tail -f server/logs/webhook.log
|
||||
```
|
||||
|
||||
## Fehlerbehebung
|
||||
|
||||
### Webhook wird nicht ausgelöst
|
||||
|
||||
- ✅ Prüfe, ob die **Target URL** korrekt ist
|
||||
- ✅ Prüfe, ob der Server erreichbar ist (`curl https://emailsorter.webklar.com/api/webhook/status`)
|
||||
- ✅ Prüfe Gitea-Logs: **Settings** → **Webhooks** → **Delivery Log**
|
||||
|
||||
### "Ungültige Webhook-Signatur" (401)
|
||||
|
||||
- ✅ Prüfe, ob `GITEA_WEBHOOK_SECRET` in `server/.env` gesetzt ist
|
||||
- ✅ Prüfe, ob das Secret in Gitea **genau gleich** ist (keine Leerzeichen!)
|
||||
- ✅ Prüfe, ob der Webhook **"application/json"** als Content-Type verwendet
|
||||
|
||||
### Deployment schlägt fehl
|
||||
|
||||
- ✅ Prüfe Server-Logs für detaillierte Fehlermeldungen
|
||||
- ✅ Prüfe, ob SSH-Zugriff funktioniert: `ssh root@91.99.156.85`
|
||||
- ✅ Prüfe, ob `npm` und `node` auf dem Server installiert sind
|
||||
- ✅ Prüfe, ob die Pfade (`DEPLOY_SERVER_PATH`) korrekt sind
|
||||
|
||||
### Frontend-Build fehlgeschlagen
|
||||
|
||||
- ✅ Prüfe, ob alle Dependencies installiert sind: `cd client && npm install`
|
||||
- ✅ Prüfe, ob `.env.production` korrekt konfiguriert ist
|
||||
- ✅ Prüfe Build-Logs für TypeScript/ESLint-Fehler
|
||||
|
||||
### Backend startet nicht neu
|
||||
|
||||
- ✅ Prüfe, ob PM2 installiert ist: `pm2 --version`
|
||||
- ✅ Prüfe, ob `USE_PM2=true` in `.env` gesetzt ist
|
||||
- ✅ Prüfe PM2-Status: `pm2 list`
|
||||
|
||||
## Sicherheit
|
||||
|
||||
### Best Practices
|
||||
|
||||
1. **Webhook-Secret:** Verwende immer ein starkes, zufälliges Secret
|
||||
2. **HTTPS:** Stelle sicher, dass dein Server HTTPS verwendet (Let's Encrypt)
|
||||
3. **Firewall:** Beschränke Webhook-Endpoint auf Gitea-IPs (optional)
|
||||
4. **Rate Limiting:** Der Webhook-Endpoint ist bereits rate-limited
|
||||
5. **Logs:** Prüfe regelmäßig die Webhook-Logs auf verdächtige Aktivitäten
|
||||
|
||||
## Alternative: Lokales Deployment ohne Server-Upload
|
||||
|
||||
Falls du den automatischen Upload auf den Server nicht möchtest, kannst du:
|
||||
|
||||
1. `DEPLOY_SERVER_HOST` **nicht** setzen
|
||||
2. Das Deployment-Skript erstellt nur den Build lokal
|
||||
3. Du lädst die Dateien manuell hoch oder verwendest ein anderes Tool
|
||||
|
||||
Der Webhook wird trotzdem ausgelöst und erstellt den Build, aber überspringt den Upload-Schritt.
|
||||
|
||||
## Manuelles Deployment auslösen
|
||||
|
||||
Du kannst das Deployment auch manuell auslösen:
|
||||
|
||||
```bash
|
||||
# Auf dem Server
|
||||
cd /var/www/emailsorter
|
||||
node scripts/deploy-to-server.mjs
|
||||
```
|
||||
|
||||
## Nächste Schritte
|
||||
|
||||
Nach erfolgreichem Setup:
|
||||
|
||||
1. ✅ Teste den Webhook mit einem kleinen Push
|
||||
2. ✅ Prüfe, ob die Website aktualisiert wurde
|
||||
3. ✅ Überwache die Logs für die ersten Deployments
|
||||
4. ✅ Dokumentiere deine spezifische Konfiguration
|
||||
|
||||
## Support
|
||||
|
||||
Bei Problemen:
|
||||
- Prüfe die Server-Logs
|
||||
- Prüfe Gitea Webhook Delivery Logs
|
||||
- Prüfe die Environment Variables
|
||||
- Teste SSH-Verbindung manuell
|
||||
51
docs/deployment/PRODUCTION_FIXES.md
Normal file
51
docs/deployment/PRODUCTION_FIXES.md
Normal file
@@ -0,0 +1,51 @@
|
||||
# Production Fixes - Wichtige Schritte
|
||||
|
||||
## ✅ Behoben
|
||||
|
||||
1. **Debug-Logs entfernt** - Alle Debug-Logs zu `127.0.0.1:7242` wurden entfernt
|
||||
2. **Favicon-Problem behoben** - `site.webmanifest` verwendet jetzt vorhandene SVG-Dateien
|
||||
|
||||
## ⚠️ Noch zu beheben (im Appwrite Dashboard)
|
||||
|
||||
### 1. Appwrite CORS-Konfiguration
|
||||
|
||||
**Problem:** Appwrite erlaubt nur `https://localhost` statt `https://emailsorter.webklar.com`
|
||||
|
||||
**Lösung:**
|
||||
1. Gehe zu: https://appwrite.webklar.com
|
||||
2. Öffne dein Projekt
|
||||
3. Gehe zu **Settings** → **Platforms** (oder **Web**)
|
||||
4. Füge eine neue Platform hinzu:
|
||||
- **Name:** Production
|
||||
- **Hostname:** `emailsorter.webklar.com`
|
||||
- **Origin:** `https://emailsorter.webklar.com`
|
||||
5. Speichere die Änderungen
|
||||
|
||||
**ODER** bearbeite die existierende Platform und ändere den Hostname/Origin zu `https://emailsorter.webklar.com`
|
||||
|
||||
### 2. Backend-Server (502 Bad Gateway)
|
||||
|
||||
**Problem:** `/api/analytics/track` gibt 502 zurück - Backend-Server läuft nicht
|
||||
|
||||
**Lösung:**
|
||||
1. SSH zum Server: `ssh user@webklar.com`
|
||||
2. Prüfe ob Server läuft: `pm2 list` oder `ps aux | grep node`
|
||||
3. Falls nicht: Starte den Server:
|
||||
```bash
|
||||
cd /path/to/ANDJJJJJJ/server
|
||||
pm2 start index.mjs --name emailsorter-api
|
||||
pm2 save
|
||||
```
|
||||
4. Prüfe Logs: `pm2 logs emailsorter-api`
|
||||
|
||||
### 3. Build deployen
|
||||
|
||||
Nach dem Commit und Push:
|
||||
1. Kopiere den Inhalt von `client/dist` auf den Web-Server
|
||||
2. Stelle sicher, dass die Dateien unter `https://emailsorter.webklar.com` erreichbar sind
|
||||
|
||||
## Nach allen Fixes
|
||||
|
||||
1. Leere den Browser-Cache (Strg+Shift+R)
|
||||
2. Teste die Website
|
||||
3. Prüfe die Browser-Konsole - sollte keine Fehler mehr zeigen
|
||||
155
docs/deployment/PRODUCTION_SETUP.md
Normal file
155
docs/deployment/PRODUCTION_SETUP.md
Normal file
@@ -0,0 +1,155 @@
|
||||
# Production Setup - emailsorter.webklar.com
|
||||
|
||||
## Probleme und Lösungen
|
||||
|
||||
### 1. Appwrite CORS-Konfiguration
|
||||
|
||||
**Problem:** Appwrite blockiert Requests von `https://emailsorter.webklar.com` weil nur `https://localhost` als Origin erlaubt ist.
|
||||
|
||||
**Lösung:**
|
||||
1. Gehe zu deiner Appwrite-Konsole: https://appwrite.webklar.com
|
||||
2. Öffne dein Projekt
|
||||
3. Gehe zu **Settings** → **Platforms** (oder **Web**)
|
||||
4. Füge eine neue Platform hinzu oder bearbeite die existierende:
|
||||
- **Name:** Production
|
||||
- **Hostname:** `emailsorter.webklar.com`
|
||||
- **Origin:** `https://emailsorter.webklar.com`
|
||||
5. Speichere die Änderungen
|
||||
|
||||
**Alternative:** Wenn du mehrere Origins brauchst, kannst du auch in Appwrite die CORS-Einstellungen anpassen, um mehrere Origins zu erlauben.
|
||||
|
||||
---
|
||||
|
||||
### 2. Backend-Server (502 Fehler)
|
||||
|
||||
**Problem:** Der Backend-Server läuft nicht oder ist nicht erreichbar.
|
||||
|
||||
**Lösung:**
|
||||
|
||||
#### Option A: Server auf demselben Server starten
|
||||
|
||||
1. **SSH zum Server:**
|
||||
```bash
|
||||
ssh user@webklar.com
|
||||
```
|
||||
|
||||
2. **Zum Projekt-Verzeichnis navigieren:**
|
||||
```bash
|
||||
cd /path/to/ANDJJJJJJ/server
|
||||
```
|
||||
|
||||
3. **Environment-Variablen setzen:**
|
||||
Erstelle oder bearbeite `.env`:
|
||||
```env
|
||||
NODE_ENV=production
|
||||
PORT=3000
|
||||
BASE_URL=https://api.emailsorter.webklar.com
|
||||
FRONTEND_URL=https://emailsorter.webklar.com
|
||||
CORS_ORIGIN=https://emailsorter.webklar.com
|
||||
|
||||
APPWRITE_ENDPOINT=https://appwrite.webklar.com/v1
|
||||
APPWRITE_PROJECT_ID=deine_projekt_id
|
||||
APPWRITE_API_KEY=dein_api_key
|
||||
APPWRITE_DATABASE_ID=email_sorter_db
|
||||
|
||||
# ... weitere Variablen
|
||||
```
|
||||
|
||||
4. **Server starten:**
|
||||
```bash
|
||||
npm install
|
||||
npm start
|
||||
```
|
||||
|
||||
#### Option B: Mit PM2 (empfohlen für Production)
|
||||
|
||||
```bash
|
||||
npm install -g pm2
|
||||
cd /path/to/ANDJJJJJJ/server
|
||||
pm2 start index.mjs --name emailsorter-api
|
||||
pm2 save
|
||||
pm2 startup
|
||||
```
|
||||
|
||||
#### Option C: Reverse Proxy konfigurieren (Nginx)
|
||||
|
||||
Falls der Server auf einem anderen Port läuft, konfiguriere Nginx:
|
||||
|
||||
```nginx
|
||||
server {
|
||||
listen 80;
|
||||
server_name api.emailsorter.webklar.com;
|
||||
|
||||
location / {
|
||||
proxy_pass http://localhost:3000;
|
||||
proxy_http_version 1.1;
|
||||
proxy_set_header Upgrade $http_upgrade;
|
||||
proxy_set_header Connection 'upgrade';
|
||||
proxy_set_header Host $host;
|
||||
proxy_cache_bypass $http_upgrade;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 3. Frontend Environment-Variablen
|
||||
|
||||
Stelle sicher, dass das Frontend die richtige Backend-URL verwendet:
|
||||
|
||||
1. **Erstelle `client/.env.production`:**
|
||||
```env
|
||||
VITE_APPWRITE_ENDPOINT=https://appwrite.webklar.com/v1
|
||||
VITE_APPWRITE_PROJECT_ID=deine_projekt_id
|
||||
VITE_API_URL=https://api.emailsorter.webklar.com
|
||||
```
|
||||
|
||||
2. **Build das Frontend:**
|
||||
```bash
|
||||
cd client
|
||||
npm run build
|
||||
```
|
||||
|
||||
3. **Deploy den Build-Ordner** (`client/dist`) zu deinem Web-Server
|
||||
|
||||
---
|
||||
|
||||
### 4. Checkliste
|
||||
|
||||
- [ ] Appwrite CORS: `https://emailsorter.webklar.com` als Origin hinzugefügt
|
||||
- [ ] Backend-Server läuft und ist erreichbar
|
||||
- [ ] Backend `.env` konfiguriert mit Production-URLs
|
||||
- [ ] Frontend `.env.production` konfiguriert
|
||||
- [ ] Frontend gebaut und deployed
|
||||
- [ ] Reverse Proxy (Nginx) konfiguriert (falls nötig)
|
||||
- [ ] SSL-Zertifikat für beide Domains (Frontend + API)
|
||||
|
||||
---
|
||||
|
||||
### 5. Testing
|
||||
|
||||
Nach dem Setup, teste:
|
||||
|
||||
1. **Frontend:** https://emailsorter.webklar.com
|
||||
2. **Backend Health:** https://api.emailsorter.webklar.com/api/health
|
||||
3. **Login:** Versuche dich einzuloggen und prüfe die Browser-Konsole auf Fehler
|
||||
|
||||
---
|
||||
|
||||
### Troubleshooting
|
||||
|
||||
**CORS-Fehler weiterhin:**
|
||||
- Prüfe, ob die Appwrite-Änderungen gespeichert wurden
|
||||
- Warte 1-2 Minuten (Cache)
|
||||
- Prüfe Browser-Konsole für genaue Fehlermeldung
|
||||
|
||||
**502 Bad Gateway:**
|
||||
- Prüfe, ob der Backend-Server läuft: `pm2 list` oder `ps aux | grep node`
|
||||
- Prüfe Server-Logs: `pm2 logs emailsorter-api` oder `tail -f server.log`
|
||||
- Prüfe Firewall-Regeln
|
||||
- Prüfe Reverse Proxy Konfiguration
|
||||
|
||||
**API nicht erreichbar:**
|
||||
- Prüfe, ob der Port 3000 offen ist
|
||||
- Prüfe, ob die Domain richtig auf den Server zeigt
|
||||
- Prüfe DNS-Einträge
|
||||
60
docs/deployment/README.md
Normal file
60
docs/deployment/README.md
Normal file
@@ -0,0 +1,60 @@
|
||||
# Deployment-Dokumentation
|
||||
|
||||
Diese Dokumentation beschreibt alle Aspekte des Deployments für E-Mail-Sorter.
|
||||
|
||||
## 📚 Inhaltsverzeichnis
|
||||
|
||||
### Automatisches Deployment
|
||||
|
||||
- **[Gitea Webhook Setup](./GITEA_WEBHOOK_SETUP.md)** - Vollständige Anleitung für automatisches Deployment via Gitea Webhook
|
||||
- **[Webhook Quick Start](./WEBHOOK_QUICK_START.md)** - Schnellstart-Anleitung (5 Minuten)
|
||||
- **[Webhook Authorization](./WEBHOOK_AUTHORIZATION.md)** - Authentifizierung und Sicherheit
|
||||
|
||||
### Manuelles Deployment
|
||||
|
||||
- **[Deployment Instructions](./DEPLOYMENT_INSTRUCTIONS.md)** - Manuelle Deployment-Schritte
|
||||
- **[Production Setup](./PRODUCTION_SETUP.md)** - Production-Server Setup
|
||||
- **[Production Fixes](./PRODUCTION_FIXES.md)** - Bekannte Probleme und Lösungen
|
||||
|
||||
## 🚀 Schnellstart
|
||||
|
||||
Für automatisches Deployment siehe [Webhook Quick Start](./WEBHOOK_QUICK_START.md).
|
||||
|
||||
## 📋 Übersicht
|
||||
|
||||
### Automatisches Deployment (Empfohlen)
|
||||
|
||||
1. **Gitea Webhook einrichten** → Siehe [GITEA_WEBHOOK_SETUP.md](./GITEA_WEBHOOK_SETUP.md)
|
||||
2. **Bei jedem Push** wird automatisch deployed
|
||||
3. **Keine manuellen Schritte** nötig
|
||||
|
||||
### Manuelles Deployment
|
||||
|
||||
1. **Frontend bauen:** `cd client && npm run build`
|
||||
2. **Dateien hochladen** auf Server
|
||||
3. **Backend neustarten** (falls nötig)
|
||||
|
||||
Siehe [DEPLOYMENT_INSTRUCTIONS.md](./DEPLOYMENT_INSTRUCTIONS.md) für Details.
|
||||
|
||||
## 🔧 Konfiguration
|
||||
|
||||
Alle Deployment-Konfigurationen finden sich in `server/.env`:
|
||||
|
||||
```bash
|
||||
# Webhook-Konfiguration
|
||||
GITEA_WEBHOOK_SECRET=...
|
||||
GITEA_WEBHOOK_AUTH_TOKEN=...
|
||||
|
||||
# Server-Deployment
|
||||
DEPLOY_SERVER_HOST=91.99.156.85
|
||||
DEPLOY_SERVER_USER=root
|
||||
DEPLOY_SERVER_PATH=/var/www/emailsorter
|
||||
USE_PM2=true
|
||||
```
|
||||
|
||||
## 📞 Support
|
||||
|
||||
Bei Problemen:
|
||||
1. Prüfe die Server-Logs
|
||||
2. Siehe [Production Fixes](./PRODUCTION_FIXES.md)
|
||||
3. Prüfe Webhook Delivery Logs in Gitea
|
||||
83
docs/deployment/WEBHOOK_AUTHORIZATION.md
Normal file
83
docs/deployment/WEBHOOK_AUTHORIZATION.md
Normal file
@@ -0,0 +1,83 @@
|
||||
# Webhook Authorization Header - Anleitung
|
||||
|
||||
Der Webhook unterstützt **zwei Authentifizierungsmethoden**:
|
||||
|
||||
1. **Signature-Verification** (Standard, von Gitea)
|
||||
2. **Authorization Header** (Optional, zusätzliche Sicherheit)
|
||||
|
||||
## Option 1: Nur Signature (Standard)
|
||||
|
||||
Das ist die Standard-Methode, die Gitea automatisch verwendet:
|
||||
|
||||
### Konfiguration
|
||||
|
||||
In `server/.env`:
|
||||
```bash
|
||||
GITEA_WEBHOOK_SECRET=dein_secret_hier
|
||||
```
|
||||
|
||||
### In Gitea
|
||||
|
||||
- **Secret:** Trage das gleiche Secret ein
|
||||
- **Authorization Header:** Nicht nötig
|
||||
|
||||
Gitea sendet automatisch den `X-Gitea-Signature` Header.
|
||||
|
||||
## Option 2: Authorization Header (Zusätzliche Sicherheit)
|
||||
|
||||
Falls du zusätzliche Sicherheit möchtest oder den Webhook manuell aufrufst:
|
||||
|
||||
### Schritt 1: Token generieren
|
||||
|
||||
```bash
|
||||
node -e "console.log(require('crypto').randomBytes(16).toString('hex'))"
|
||||
```
|
||||
|
||||
### Schritt 2: Server konfigurieren
|
||||
|
||||
In `server/.env`:
|
||||
```bash
|
||||
GITEA_WEBHOOK_SECRET=dein_secret_hier
|
||||
GITEA_WEBHOOK_AUTH_TOKEN=dein_auth_token_hier
|
||||
```
|
||||
|
||||
### Schritt 3: In Gitea konfigurieren
|
||||
|
||||
Gitea unterstützt **keine** Authorization Header direkt, aber du kannst:
|
||||
|
||||
#### Option A: Nur Signature verwenden (empfohlen)
|
||||
- Lass `GITEA_WEBHOOK_AUTH_TOKEN` leer
|
||||
- Nur `GITEA_WEBHOOK_SECRET` verwenden
|
||||
|
||||
#### Option B: Manuelle Webhook-Aufrufe
|
||||
Wenn du den Webhook manuell aufrufst (z.B. via curl), verwende:
|
||||
|
||||
```bash
|
||||
curl -X POST https://emailsorter.webklar.com/api/webhook/gitea \
|
||||
-H "Content-Type: application/json" \
|
||||
-H "X-Gitea-Signature: sha256=..." \
|
||||
-H "Authorization: Bearer dein_auth_token_hier" \
|
||||
-d '{"ref":"refs/heads/main",...}'
|
||||
```
|
||||
|
||||
## Option 3: Beide Methoden kombinieren
|
||||
|
||||
Für maximale Sicherheit kannst du beide verwenden:
|
||||
|
||||
```bash
|
||||
# In server/.env
|
||||
GITEA_WEBHOOK_SECRET=secret_fuer_signature
|
||||
GITEA_WEBHOOK_AUTH_TOKEN=token_fuer_auth_header
|
||||
```
|
||||
|
||||
**Verhalten:**
|
||||
- Wenn beide gesetzt sind, müssen **beide** passen
|
||||
- Wenn nur eine gesetzt ist, reicht diese
|
||||
|
||||
## Empfehlung
|
||||
|
||||
**Für Gitea-Webhooks:** Verwende nur `GITEA_WEBHOOK_SECRET` (Signature)
|
||||
|
||||
**Für manuelle Aufrufe:** Verwende `GITEA_WEBHOOK_AUTH_TOKEN` (Authorization Header)
|
||||
|
||||
**Für maximale Sicherheit:** Verwende beide
|
||||
61
docs/deployment/WEBHOOK_QUICK_START.md
Normal file
61
docs/deployment/WEBHOOK_QUICK_START.md
Normal file
@@ -0,0 +1,61 @@
|
||||
# Gitea Webhook - Quick Start Guide
|
||||
|
||||
## 🚀 Schnellstart (5 Minuten)
|
||||
|
||||
### Schritt 1: Secret generieren
|
||||
|
||||
```bash
|
||||
node -e "console.log(require('crypto').randomBytes(16).toString('hex'))"
|
||||
```
|
||||
|
||||
Kopiere das generierte Secret - du brauchst es gleich!
|
||||
|
||||
### Schritt 2: Server konfigurieren
|
||||
|
||||
Füge zu `server/.env` hinzu:
|
||||
|
||||
```bash
|
||||
GITEA_WEBHOOK_SECRET=dein_generiertes_secret_hier
|
||||
DEPLOY_SERVER_HOST=91.99.156.85
|
||||
DEPLOY_SERVER_USER=root
|
||||
DEPLOY_SERVER_PATH=/var/www/emailsorter
|
||||
USE_PM2=true
|
||||
```
|
||||
|
||||
### Schritt 3: Gitea Webhook einrichten
|
||||
|
||||
1. Gehe zu deinem Repository → **Settings** → **Webhooks**
|
||||
2. Klicke **Add Webhook** → **Gitea**
|
||||
3. Fülle aus:
|
||||
- **Target URL:** `https://emailsorter.webklar.com/api/webhook/gitea`
|
||||
- **Secret:** `dein_generiertes_secret_hier` (aus Schritt 1)
|
||||
- **Trigger On:** ✅ **Push Events**
|
||||
- **Branch Filter:** `main` oder `master`
|
||||
4. Klicke **Add Webhook**
|
||||
|
||||
### Schritt 4: Testen
|
||||
|
||||
```bash
|
||||
git add .
|
||||
git commit -m "test: Webhook test"
|
||||
git push
|
||||
```
|
||||
|
||||
Prüfe die Server-Logs - du solltest sehen:
|
||||
```
|
||||
📥 Gitea Webhook empfangen
|
||||
🚀 Starte Deployment...
|
||||
✅ Deployment erfolgreich abgeschlossen
|
||||
```
|
||||
|
||||
## ✅ Fertig!
|
||||
|
||||
Jetzt wird bei jedem Push automatisch deployed!
|
||||
|
||||
## 📚 Weitere Informationen
|
||||
|
||||
Siehe [GITEA_WEBHOOK_SETUP.md](./GITEA_WEBHOOK_SETUP.md) für:
|
||||
- Detaillierte Anleitung
|
||||
- Fehlerbehebung
|
||||
- Sicherheitsbest Practices
|
||||
- Server-Upload Konfiguration
|
||||
Reference in New Issue
Block a user