162 lines
6.9 KiB
Markdown
162 lines
6.9 KiB
Markdown
# Canteen Menu – Speisekarte für die Betriebskantine
|
||
|
||
Digitale Speisekarte für eine Firmenkantine (ca. 250 Mitarbeiter) mit
|
||
öffentlicher Wochenansicht, Kantinen-Bereich zur Pflege der Gerichte und
|
||
Admin-Bereich für Benutzerverwaltung und Branding.
|
||
|
||
**Stack:** Next.js 16 (App Router, TypeScript, Tailwind CSS) · Supabase
|
||
(PostgreSQL, Auth inkl. Passkeys, Storage, Row Level Security)
|
||
|
||
Änderungen je Version stehen in [CHANGELOG.md](CHANGELOG.md), Git-Tags
|
||
markieren die jeweiligen Versionsstände (`git tag`).
|
||
|
||
## Funktionen
|
||
|
||
| Bereich | Funktionen |
|
||
| --- | --- |
|
||
| Öffentlich (ohne Login) | Wochenplan Mo–Fr mit den Bereichen Brotzeit (09:00–10:00), Mittagessen, Mittagessen vegetarisch und Suppe (je 11:30–13:30); Navigation vorherige/nächste Woche/Heute; auf schmalen Bildschirmen umschaltbare Tages-/Wochenansicht (Tag ist Standard); Logo zentriert über der Karte; Allergen-/Zusatzstoff-Kürzel je Gericht, Legende unterhalb der Karte |
|
||
| Kantinen-Team (`/intern`) | Gerichte anlegen/bearbeiten/löschen (inkl. Live-Suche und Mehrfachauswahl zum Batch-Löschen) mit Allergenen/Zusatzstoffen je Gericht; Gerichte Tagen/Bereichen zuweisen (mehrere pro Zelle) und wieder entfernen; globale Allergen-/Zusatzstofflisten pflegen; eigenes Konto verwalten (Name, E-Mail, Passwort, Passkeys, Passwort-Anmeldung an/aus) |
|
||
| Admin (`/admin`) | Kantinenmitarbeiter anlegen/bearbeiten/löschen (inkl. Passwort-Reset mit Wiederholung und Rollenvergabe); Farbgebung der Speisekarte anpassen; Logo und Favicon hochladen/entfernen |
|
||
|
||
Anmeldung mit E-Mail + Passwort oder alternativ per **Passkey**
|
||
(Registrierung im eigenen Konto nach dem ersten Login). Die
|
||
Passwort-Anmeldung kann pro Konto deaktiviert werden, sobald mindestens
|
||
ein Passkey registriert ist.
|
||
|
||
## Projektstruktur
|
||
|
||
```
|
||
app/ Next.js-Routen
|
||
page.tsx Öffentliche Speisekarte
|
||
login/ Login (Passwort + Passkey)
|
||
intern/ Kantinen-Bereich (Rolle: staff oder admin)
|
||
admin/ Verwaltung (Rolle: admin)
|
||
api/admin/users/ Benutzerverwaltung (serverseitig, Service-Role-Key)
|
||
components/ Client-Komponenten (WeekEditor, DishManager, …)
|
||
lib/supabase/ Supabase-Clients (Browser / Server / Admin)
|
||
lib/ Typen, Datums-/Formatierungshelfer
|
||
proxy.ts Session-Refresh + Schutz von /intern und /admin
|
||
supabase/migrations/ Schema & Seed-Daten (Referenz/Doku)
|
||
supabase/local/ Skripte + Dumps für die lokale PostgreSQL-Kopie
|
||
scripts/ Hilfsskripte (DB-Migration, lokaler Sync)
|
||
```
|
||
|
||
## Entwicklung
|
||
|
||
Voraussetzung in beiden Varianten: `.env.local` mit den Werten aus
|
||
`.env.example` (liegt lokal bereits vor und ist per `.gitignore` vom
|
||
Repo ausgeschlossen).
|
||
|
||
**Variante A – Docker (nichts vorinstallieren außer Docker):**
|
||
|
||
```bash
|
||
docker compose --env-file .env.local --profile dev up dev
|
||
# http://localhost:3000 (Hot-Reload, Quellcode wird gemountet)
|
||
```
|
||
|
||
**Variante B – lokal installiertes Node.js:**
|
||
|
||
```bash
|
||
npm install
|
||
npm run dev # http://localhost:3000 (bindet an 0.0.0.0, auch im LAN erreichbar)
|
||
```
|
||
|
||
## Umgebungsvariablen (Live-Betrieb)
|
||
|
||
Beim Webserver/Hoster müssen genau diese drei Variablen hinterlegt werden
|
||
(Werte: Supabase-Dashboard → Project Settings → API Keys):
|
||
|
||
| Variable | Bedeutung | Geheim? |
|
||
| --- | --- | --- |
|
||
| `NEXT_PUBLIC_SUPABASE_URL` | URL des Supabase-Projekts, z. B. `https://hvzikwjoyhoakedlywhj.supabase.co` | nein |
|
||
| `NEXT_PUBLIC_SUPABASE_ANON_KEY` | Öffentlicher anon-Key (RLS schützt die Daten) | nein |
|
||
| `SUPABASE_SERVICE_ROLE_KEY` | Service-Role-Key für die Benutzerverwaltung | **ja – niemals im Browser/Repo!** |
|
||
| `APP_URL` | Öffentliche URL der App, z. B. `https://menu.example.de` (Origin-Check hinter Reverse-Proxy; zugleich Passkey-Domain) | nein |
|
||
| `SITE_TITLE` | Titel im Browser-Tab und Überschrift ohne Logo, Default `Canteen Menu` | nein |
|
||
|
||
Build & Start auf dem Server – **mit Docker** (empfohlen, Node.js und
|
||
PostgreSQL müssen nicht installiert sein):
|
||
|
||
```bash
|
||
docker compose --env-file .env.local up -d --build
|
||
# App: Port 3000 (hinter Reverse-Proxy mit HTTPS betreiben)
|
||
# Lokale DB-Kopie: Port 5433 (Dienst "db", optional)
|
||
```
|
||
|
||
Oder klassisch ohne Docker:
|
||
|
||
```bash
|
||
npm ci
|
||
npm run build
|
||
npm run start # Port 3000, bindet an 0.0.0.0 (hinter Reverse-Proxy betreiben)
|
||
```
|
||
|
||
### Passkeys für die Produktions-Domain freischalten
|
||
|
||
Passkeys sind an die Domain gebunden. Aktuell ist `localhost` konfiguriert.
|
||
Vor dem Livegang: `APP_URL` auf die öffentliche URL setzen und einmalig
|
||
|
||
```bash
|
||
SUPABASE_ACCESS_TOKEN=<personal-access-token> node scripts/configure-passkeys.mjs
|
||
```
|
||
|
||
ausführen (liest `APP_URL` aus der Umgebung; die URL kann alternativ als
|
||
Argument übergeben werden). Ohne lokales Node.js geht es auch über Docker:
|
||
|
||
```bash
|
||
docker run --rm -v .:/app -w /app \
|
||
-e SUPABASE_ACCESS_TOKEN=<token> -e APP_URL=https://menu.example.de \
|
||
node:24-alpine node scripts/configure-passkeys.mjs
|
||
```
|
||
|
||
Achtung: Bereits registrierte Passkeys der alten Domain verlieren dabei
|
||
ihre Gültigkeit und müssen neu registriert werden.
|
||
|
||
## Datenbank
|
||
|
||
### Supabase (führende Datenbank)
|
||
|
||
- Projekt-Ref: `hvzikwjoyhoakedlywhj` (Region `eu-central-1`, Frankfurt)
|
||
- Schema und Seed-Daten: `supabase/migrations/0001_init.sql` und `0002_seed.sql`
|
||
- Ausführen weiterer SQL-Dateien:
|
||
`SUPABASE_ACCESS_TOKEN=<token> node scripts/db-apply.mjs <datei.sql>`
|
||
|
||
Sicherheitsmodell (Row Level Security):
|
||
|
||
- `anon` darf ausschließlich lesen (Speisekarte, Bereiche, Allergene,
|
||
Zusatzstoffe, Einstellungen).
|
||
- `staff`/`admin` (Rolle im `profiles`-Eintrag) pflegen Gerichte,
|
||
Wochenplan und Kennzeichnungen.
|
||
- Nur `admin` ändert Einstellungen (Farben/Logo) und verwaltet Benutzer;
|
||
das Anlegen/Löschen von Benutzern läuft serverseitig über den
|
||
Service-Role-Key (`app/api/admin/users`).
|
||
- Storage-Bucket `branding` (Logo): öffentlich lesbar, Schreibzugriff nur Admin.
|
||
|
||
### Lokale PostgreSQL-Kopie
|
||
|
||
Die Datenbank `canteen_menu` (Kopie von Schema + Daten aus Supabase, inkl.
|
||
Minimal-Stubs für `auth`/`storage`) gibt es in zwei Varianten:
|
||
|
||
**Per Docker:** Der Dienst `db` aus `docker-compose.yml` spielt die
|
||
Skripte aus `supabase/local/` beim ersten Start automatisch ein
|
||
(PostgreSQL 17, Host-Port 5433 – 5432 ist meist durch eine native
|
||
PostgreSQL-Installation belegt –, Passwort über `LOCAL_PG_PASSWORD`).
|
||
|
||
**Nativ:** Auf dem Entwicklungsrechner läuft PostgreSQL 17 mit derselben
|
||
Datenbank. Neu aufbauen bzw. aktualisieren:
|
||
|
||
```powershell
|
||
$env:SUPABASE_DB_PASSWORD = "<Supabase-DB-Passwort>"
|
||
$env:LOCAL_PG_PASSWORD = "<lokales postgres-Passwort>"
|
||
powershell -File scripts\sync-local-db.ps1
|
||
```
|
||
|
||
Hinweis: Die lokale Kopie dient als Ablage/Backup und für Auswertungen.
|
||
Logins (Passwort-Hashes, Passkeys) verbleiben ausschließlich in Supabase.
|
||
|
||
## Zugangsdaten
|
||
|
||
Die Anmeldedaten (Admin, Demo-Mitarbeiter, Datenbank-Passwörter) stehen in
|
||
`ZUGANGSDATEN.md` – diese Datei ist bewusst **nicht** im Repository
|
||
(`.gitignore`). Nach dem ersten Login bitte die Startpasswörter ändern.
|