till/managarten
1
0
Fork 0
mirror of https://github.com/Memo-2023/mana-monorepo.git synced 2026-05-14 23:21:08 +02:00
Code Issues Projects Releases Packages Wiki Activity Actions 4
managarten/docs/CLOUDFLARE_FALLBACK.md
Till JS 8e8b6ac65f fix(mana-auth) + chore: rewrite /api/v1/auth/login JWT mint, remove Matrix stack 
This commit bundles two unrelated changes that were swept together by an
accidental `git add -A` in another working session. Documented here so the
history reflects what's actually inside.

═══════════════════════════════════════════════════════════════════════
1. fix(mana-auth): /api/v1/auth/login mints JWT via auth.handler instead
   of api.signInEmail
═══════════════════════════════════════════════════════════════════════

Previous attempt (commit 55cc75e7d) tried to fix the broken JWT mint in
/api/v1/auth/login by switching the cookie name from `mana.session_token`
to `__Secure-mana.session_token` for production. That was necessary but
not sufficient: Better Auth's session cookie value isn't just the raw
session token, it's `<token>.<HMAC>` where the HMAC is derived from the
better-auth secret. Reconstructing the cookie from auth.api.signInEmail's
JSON response only gave us the raw token, so /api/auth/token's
get-session middleware still couldn't validate it and the JWT mint kept
silently failing.

Real fix: do the sign-in via auth.handler (the HTTP path) rather than
auth.api.signInEmail (the SDK path). The handler returns a real fetch
Response with a Set-Cookie header containing the fully signed cookie
envelope. We capture that header verbatim and forward it as the cookie
on the /api/auth/token request, which now passes validation and mints
the JWT correctly.

Verified end-to-end on auth.mana.how:

  $ curl -X POST https://auth.mana.how/api/v1/auth/login \
      -d '{"email":"...","password":"..."}'
  {
    "user": {...},
    "token": "<session token>",
    "accessToken": "eyJhbGciOiJFZERTQSI...",   ← real JWT now
    "refreshToken": "<session token>"
  }

Side benefits:
- Email-not-verified path is now handled by checking
  signInResponse.status === 403 directly, no more catching APIError
  with the comment-noted async-stream footgun.
- X-Forwarded-For is forwarded explicitly so Better Auth's rate limiter
  and our security log see the real client IP.
- The leftover catch block now only handles unexpected exceptions
  (network errors etc); the FORBIDDEN-checking logic in it is dead but
  harmless and left in for defense in depth.

═══════════════════════════════════════════════════════════════════════
2. chore: remove the entire self-hosted Matrix stack (Synapse, Element,
   Manalink, mana-matrix-bot)
═══════════════════════════════════════════════════════════════════════

The Matrix subsystem ran parallel to the main Mana product without any
load-bearing integration: the unified web app never imported matrix-js-sdk,
the chat module uses mana-sync (local-first), and mana-matrix-bot's
plugins duplicated features the unified app already ships natively.
Keeping it alive cost a Synapse + Element + matrix-web + bot container
quartet, three Cloudflare routes, an OIDC provider plugin in mana-auth,
and a steady drip of devlog/dependency churn.

Removed:
- apps/matrix (Manalink web + mobile, ~150 files)
- services/mana-matrix-bot (Go bot with ~20 plugins)
- docker/matrix configs (Synapse + Element)
- synapse/element-web/matrix-web/mana-matrix-bot services in
  docker-compose.macmini.yml
- matrix.mana.how/element.mana.how/link.mana.how Cloudflare tunnel routes
- OIDC provider plugin + matrix-synapse trustedClient + matrixUserLinks
  table from mana-auth (oauth_* schema definitions also removed)
- MatrixService import path in mana-media (importFromMatrix endpoint)
- Matrix notification channel in mana-notify (worker, metrics, config,
  channel_type enum, MatrixOptions handler)
- Matrix entries from shared-branding (mana-apps + app-icons),
  notify-client, the i18n bundle, the observatory map, the credits
  app-label list, the landing footer/apps page, the prometheus + alerts
  + promtail tier mappings, and the matrix-related deploy paths in
  cd-macmini.yml + ci.yml

Devlog/manascore/blueprint entries that mention Matrix are left intact
as historical record. The oauth_* + matrix_user_links Postgres tables
stay on existing prod databases — code can no longer write to them, drop
them in a follow-up migration if you want them gone for real.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2026-04-08 16:32:13 +02:00

277 lines
6.1 KiB
Markdown
Raw Blame History

# Cloudflare Tunnel Fallback-Plan
> Was tun wenn Cloudflare ausfällt oder den Account sperrt?
## Risiko
Cloudflare Tunnel ist der **einzige** Weg vom Internet zum Mac Mini. Wenn Cloudflare nicht erreichbar ist:
- Alle *.mana.how Subdomains sind offline
- SSH nur im lokalen Netzwerk möglich
- Kein Deployment, kein Monitoring
**Wahrscheinlichkeit:** Gering (Cloudflare hat >99.99% Uptime), aber Accountsperren oder Policy-Änderungen sind ein Risiko.
## Plan B: WireGuard + Caddy auf Hetzner VPS
### Architektur
```
Internet
│
▼
Hetzner VPS (€3.79/Monat, CX22)
├── Caddy (Reverse Proxy + Auto-TLS)
├── WireGuard Server
└── DNS: *.mana.how → VPS IP
│
│ WireGuard Tunnel (verschlüsselt)
│
▼
Mac Mini (WireGuard Client)
├── Alle Services auf localhost
└── Erreichbar über WireGuard-IP (z.B. 10.0.0.2)
```
### Vorteile
- **Kein Vendor Lock-in:** Hetzner ist deutscher Anbieter
- **Eigene IP:** Keine Abhängigkeit von Cloudflare Proxy
- **WireGuard:** Schneller als Cloudflare Tunnel (~10% weniger Latenz)
- **Let's Encrypt:** Caddy macht TLS automatisch
- **Kosten:** €3.79/Monat (CX22: 2 vCPU, 4 GB RAM, 40 GB SSD)
### Einrichtung VPS (einmalig, ~1 Stunde)
#### 1. Hetzner VPS erstellen
```bash
# CX22 (kleinster mit genug RAM für Caddy + WireGuard)
# Standort: Falkenstein (DE) oder Nürnberg (DE)
# OS: Ubuntu 24.04
# SSH Key: Mac Mini public key
```
#### 2. WireGuard installieren
**Auf dem VPS:**
```bash
apt update && apt install -y wireguard
# Keys generieren
wg genkey | tee /etc/wireguard/server_private.key | wg pubkey > /etc/wireguard/server_public.key
chmod 600 /etc/wireguard/server_private.key
# Config erstellen
cat > /etc/wireguard/wg0.conf << EOF
[Interface]
Address = 10.0.0.1/24
PrivateKey = $(cat /etc/wireguard/server_private.key)
ListenPort = 51820
[Peer]
# Mac Mini
PublicKey = <MAC_MINI_PUBLIC_KEY>
AllowedIPs = 10.0.0.2/32
EOF
systemctl enable --now wg-quick@wg0
```
**Auf dem Mac Mini:**
```bash
brew install wireguard-tools
# Keys generieren
wg genkey | tee /etc/wireguard/client_private.key | wg pubkey > /etc/wireguard/client_public.key
# Config
cat > /etc/wireguard/wg0.conf << EOF
[Interface]
Address = 10.0.0.2/24
PrivateKey = $(cat /etc/wireguard/client_private.key)
[Peer]
PublicKey = <VPS_PUBLIC_KEY>
Endpoint = <VPS_IP>:51820
AllowedIPs = 10.0.0.0/24
PersistentKeepalive = 25
EOF
wg-quick up wg0
```
#### 3. Caddy installieren (VPS)
```bash
apt install -y debian-keyring debian-archive-keyring apt-transport-https
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | tee /etc/apt/sources.list.d/caddy-stable.list
apt update && apt install caddy
```
#### 4. Caddyfile erstellen (VPS)
```Caddyfile
# /etc/caddy/Caddyfile
# Alle Domains → Mac Mini via WireGuard
mana.how {
reverse_proxy 10.0.0.2:5000
}
auth.mana.how {
reverse_proxy 10.0.0.2:3001
}
chat.mana.how {
reverse_proxy 10.0.0.2:5010
}
chat-api.mana.how {
reverse_proxy 10.0.0.2:3030
}
todo.mana.how {
reverse_proxy 10.0.0.2:5011
}
todo-api.mana.how {
reverse_proxy 10.0.0.2:3031
}
calendar.mana.how {
reverse_proxy 10.0.0.2:5012
}
calendar-api.mana.how {
reverse_proxy 10.0.0.2:3032
}
clock.mana.how {
reverse_proxy 10.0.0.2:5013
}
clock-api.mana.how {
reverse_proxy 10.0.0.2:3033
}
contacts.mana.how {
reverse_proxy 10.0.0.2:5014
}
contacts-api.mana.how {
reverse_proxy 10.0.0.2:3034
}
storage.mana.how {
reverse_proxy 10.0.0.2:5015
}
storage-api.mana.how {
reverse_proxy 10.0.0.2:3035
}
presi.mana.how {
reverse_proxy 10.0.0.2:5016
}
presi-api.mana.how {
reverse_proxy 10.0.0.2:3036
}
nutriphi.mana.how {
reverse_proxy 10.0.0.2:5017
}
nutriphi-api.mana.how {
reverse_proxy 10.0.0.2:3037
}
photos.mana.how {
reverse_proxy 10.0.0.2:5019
}
photos-api.mana.how {
reverse_proxy 10.0.0.2:3039
}
mukke.mana.how {
reverse_proxy 10.0.0.2:5180
}
picture.mana.how {
reverse_proxy 10.0.0.2:5021
}
picture-api.mana.how {
reverse_proxy 10.0.0.2:3040
}
playground.mana.how {
reverse_proxy 10.0.0.2:5090
}
grafana.mana.how {
reverse_proxy 10.0.0.2:8000
}
stats.mana.how {
reverse_proxy 10.0.0.2:8010
}
glitchtip.mana.how {
reverse_proxy 10.0.0.2:8020
}
```
#### 5. DNS umstellen (Failover-Schritt)
Beim Ausfall von Cloudflare Tunnel:
```bash
# 1. WireGuard-Verbindung prüfen
ssh mana-server "ping -c1 10.0.0.1" # Ping VPS via WireGuard
# 2. DNS bei Cloudflare umstellen (alle *.mana.how → VPS IP)
# Cloudflare Dashboard → DNS → *.mana.how → A Record → <VPS_IP>
# ODER falls Cloudflare komplett down:
# Domain zu anderem DNS-Provider transferieren (vorher vorbereiten!)
# 3. Caddy starten
ssh vps "systemctl start caddy"
# 4. Prüfen
curl https://mana.how # Sollte über VPS → WireGuard → Mac Mini routen
```
## Failover-Checkliste
| # | Schritt | Zeit | Verantwortlich |
|---|---------|------|----------------|
| 1 | Feststellen: Cloudflare Tunnel ist down | Auto (Health Check Alert) | Automatisch |
| 2 | VPS WireGuard-Verbindung prüfen | 1 Min | Admin |
| 3 | DNS auf VPS-IP umstellen | 5 Min | Admin (Cloudflare Dashboard) |
| 4 | Caddy aktivieren | 1 Min | Admin (SSH zu VPS) |
| 5 | TLS-Zertifikate generieren lassen | 2-5 Min | Automatisch (Caddy + Let's Encrypt) |
| 6 | Alle Services testen | 5 Min | Admin |
| **Gesamt** | | **~15 Min** | |
## Vorbereitung (jetzt erledigen)
- [ ] Hetzner Account erstellen
- [ ] VPS bestellen (CX22, €3.79/Monat)
- [ ] WireGuard einrichten (VPS + Mac Mini)
- [ ] WireGuard-Verbindung testen
- [ ] Caddyfile erstellen (alle Domains)
- [ ] DNS-Failover-Prozedur testen (mit Test-Subdomain)
- [ ] Failover-Checkliste ausdrucken / im Wiki speichern
## Plan C: Direkte IP
Falls auch Hetzner nicht verfügbar:
1. ISP kontaktieren für feste IP-Adresse
2. Port-Forwarding auf Router einrichten (80, 443)
3. Let's Encrypt Zertifikat via DNS-Challenge (kein HTTP nötig)
4. DNS bei einem dritten Provider (z.B. Hetzner DNS, Gandi)
**Nachteil:** Consumer-ISPs blockieren oft Port 25 (E-Mail) und Port 80/443 ist nicht garantiert.
Reference in a new issue View git blame Copy permalink