mirror of
https://github.com/Memo-2023/mana-monorepo.git
synced 2026-05-15 22:59:40 +02:00
8e8b6ac65f
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>
145 lines
5.4 KiB
Markdown
145 lines
5.4 KiB
Markdown
# Cloudflare DNS — Domains & Konfiguration
|
|
|
|
> Stand: 2026-03-24
|
|
|
|
## Ausstehende Aktionen im Cloudflare Dashboard
|
|
|
|
### Landing Pages auf Tunnel umstellen
|
|
|
|
Landing Pages laufen jetzt **self-hosted** via Nginx auf dem Mac Mini (Port 4400). Die DNS-Records müssen von Cloudflare Pages auf den Cloudflare Tunnel umgestellt werden.
|
|
|
|
**Tunnel-ID:** `bb0ea86d-8253-4a54-838b-107bb7945be9`
|
|
|
|
**Im Cloudflare Dashboard → DNS → mana.how:**
|
|
|
|
Für jede Domain: **CNAME Record hinzufügen** (oder bestehenden ändern), Proxied (orange Wolke):
|
|
|
|
| Domain | Typ | Wert | Status |
|
|
|--------|-----|------|--------|
|
|
| `it` | CNAME | `bb0ea86d-8253-4a54-838b-107bb7945be9.cfargotunnel.com` | **Neu erstellen** |
|
|
| `citycorners` | CNAME | `bb0ea86d-8253-4a54-838b-107bb7945be9.cfargotunnel.com` | **Neu erstellen** |
|
|
| `nutriphi` | CNAME | `bb0ea86d-8253-4a54-838b-107bb7945be9.cfargotunnel.com` | **Neu erstellen** |
|
|
| `cards` | CNAME | `bb0ea86d-8253-4a54-838b-107bb7945be9.cfargotunnel.com` | **Neu erstellen** |
|
|
| `docs` | CNAME | `bb0ea86d-8253-4a54-838b-107bb7945be9.cfargotunnel.com` | **Neu erstellen** |
|
|
|
|
**Für bestehende Landing-Domains (aktuell auf CF Pages):**
|
|
|
|
Diese Domains zeigen noch auf Cloudflare Pages. Um sie auf Self-Hosted umzustellen:
|
|
|
|
1. **Pages → [Projekt] → Custom domains → Remove** (Domain vom Pages-Projekt entfernen)
|
|
2. **DNS → CNAME auf Tunnel-ID ändern** (wie oben)
|
|
|
|
| Domain | Aktuell | Umstellen auf |
|
|
|--------|---------|---------------|
|
|
| `chats.mana.how` | CF Pages (`chat-landing`) | Tunnel → `localhost:4400` |
|
|
| `pics.mana.how` | CF Pages (`picture-landing`) | Tunnel → `localhost:4400` |
|
|
| `zitares.mana.how` | CF Pages (`zitare-landing`) | Tunnel → `localhost:4400` |
|
|
| `presis.mana.how` | CF Pages (`presi-landing`) | Tunnel → `localhost:4400` |
|
|
| `clocks.mana.how` | CF Pages (`clocks-landing`) | Tunnel → `localhost:4400` |
|
|
|
|
**Hinweis:** Die Umstellung kann schrittweise erfolgen — erst neue Domains, dann bestehende migrieren.
|
|
|
|
### Reihenfolge
|
|
|
|
1. **Zuerst:** Neue Domains erstellen (`it`, `citycorners`, `nutriphi`, `cards`, `docs`)
|
|
2. **Danach:** Bestehende Landing-Domains von Pages auf Tunnel migrieren (eine nach der anderen, testen)
|
|
3. **Zuletzt:** Alte CF Pages Projekte löschen (optional, kosten nichts)
|
|
|
|
---
|
|
|
|
## Architektur
|
|
|
|
```
|
|
Internet
|
|
│
|
|
▼
|
|
Cloudflare DNS (*.mana.how)
|
|
│
|
|
▼
|
|
Cloudflare Tunnel (bb0ea86d...)
|
|
│
|
|
├── Apps (Web + API): chat.mana.how → localhost:5010
|
|
├── Services: auth.mana.how → localhost:3001
|
|
├── Landing Pages: it.mana.how → localhost:4400 (Nginx)
|
|
└── Monitoring: grafana.mana.how → localhost:8000
|
|
```
|
|
|
|
**Nginx Landing Container** (`mana-infra-landings`, Port 4400):
|
|
- Routet nach `Host`-Header zu verschiedenen `dist/`-Ordnern
|
|
- Config: `docker/nginx/landings.conf`
|
|
- Daten: `/Volumes/ManaData/landings/{name}/`
|
|
- Build: `./scripts/mac-mini/build-landings.sh`
|
|
|
|
---
|
|
|
|
## Alle Domains
|
|
|
|
### Apps (via Tunnel → Docker Container)
|
|
|
|
| Domain | Service | Port |
|
|
|--------|---------|------|
|
|
| `mana.how` | Dashboard Web | 5000 |
|
|
| `auth.mana.how` | Auth API | 3001 |
|
|
| `chat.mana.how` | Chat Web | 5010 |
|
|
| `chat-api.mana.how` | Chat API | 3030 |
|
|
| `todo.mana.how` | Todo Web | 5011 |
|
|
| `todo-api.mana.how` | Todo API | 3031 |
|
|
| `calendar.mana.how` | Calendar Web | 5012 |
|
|
| `calendar-api.mana.how` | Calendar API | 3032 |
|
|
| `clock.mana.how` | Clock Web | 5013 |
|
|
| `clock-api.mana.how` | Clock API | 3033 |
|
|
| `contacts.mana.how` | Contacts Web | 5014 |
|
|
| `contacts-api.mana.how` | Contacts API | 3034 |
|
|
| `storage.mana.how` | Storage Web | 5015 |
|
|
| `storage-api.mana.how` | Storage API | 3035 |
|
|
| `presi.mana.how` | Presi Web | 5016 |
|
|
| `nutriphi.mana.how` | NutriPhi Web | 5017 |
|
|
| `photos.mana.how` | Photos Web | 5019 |
|
|
| `mukke.mana.how` | Mukke Web | 5180 |
|
|
| `picture.mana.how` | Picture Web | 5021 |
|
|
| `playground.mana.how` | LLM Playground | 5090 |
|
|
|
|
### Landing Pages (via Tunnel → Nginx 4400)
|
|
|
|
| Domain | Landing | Nginx Root |
|
|
|--------|---------|------------|
|
|
| `it.mana.how` | IT Souveränität | `/srv/landings/it` |
|
|
| `chats.mana.how` | Chat Landing | `/srv/landings/chat` |
|
|
| `pics.mana.how` | Picture Landing | `/srv/landings/picture` |
|
|
| `zitares.mana.how` | Zitare Landing | `/srv/landings/zitare` |
|
|
| `presis.mana.how` | Presi Landing | `/srv/landings/presi` |
|
|
| `clocks.mana.how` | Clock Landing | `/srv/landings/clock` |
|
|
| `cards.mana.how` | Cards Landing | `/srv/landings/cards` |
|
|
| `nutriphi.mana.how` | NutriPhi Landing | `/srv/landings/nutriphi` |
|
|
| `citycorners.mana.how` | CityCorners Landing | `/srv/landings/citycorners` |
|
|
| `docs.mana.how` | Dokumentation | `/srv/landings/docs` |
|
|
|
|
### Services & Monitoring (via Tunnel)
|
|
|
|
| Domain | Service | Port |
|
|
|--------|---------|------|
|
|
| `grafana.mana.how` | Grafana | 8000 |
|
|
| `stats.mana.how` | Umami Analytics | 8010 |
|
|
| `glitchtip.mana.how` | GlitchTip Errors | 8020 |
|
|
| `ssh.mana.how` | SSH Access | 22 |
|
|
|
|
---
|
|
|
|
## Landing Pages deployen
|
|
|
|
```bash
|
|
# Alle Landings bauen und nach /Volumes/ManaData/landings/ kopieren
|
|
./scripts/mac-mini/build-landings.sh
|
|
|
|
# Nginx neuladen
|
|
docker restart mana-infra-landings
|
|
```
|
|
|
|
## Neue Landing Page hinzufügen
|
|
|
|
1. Landing erstellen (Astro in `apps/{app}/apps/landing/` oder `services/{name}/`)
|
|
2. Build-Script (`scripts/mac-mini/build-landings.sh`) erweitern
|
|
3. Nginx Server-Block in `docker/nginx/landings.conf` hinzufügen
|
|
4. Cloudflare Tunnel Ingress in `cloudflared-config.yml` hinzufügen
|
|
5. DNS CNAME im Cloudflare Dashboard erstellen
|
|
6. Bauen, deployen, cloudflared neustarten
|