Gourmet Fesztivál — Rendelési Rendszer Terv

1 Rendszer áttekintése

A rendszer célja, hogy a fesztiválon tartózkodó látogatók QR kód beolvasásával gyorsan, egyszerűen tudjanak ételt rendelni a két partner standjától, futáros kiszállítással, helyszíni fizetéssel (POS terminál). Nincs bejelentkezés, nincs GPS, nincs online fizetés.

📱

QR kód → Rendelés

Kint elhelyezett kódok irányítják a látogatót. Nincs letöltendő app, böngészőből fut.

🛒

Kosár + Standszám

Menüválasztás, kosár összeállítás, standszám + e-mail megadása. Semmi más adat.

📧

E-mail visszaigazolás

Időkorlátolt link (15 perc). Megerősítés után a rendelés aktívvá válik és generálódik a rendelési szám.

🛵

Futáros kézbesítés

A futár a megadott standhoz viszi a rendelést, ott fizet a vendég POS terminállal.

🔒

Visszaélés-védelem

Többrétegű védelem az egyszer használatos e-mail spam ellen. Részletek a 4. fejezetben.

🖥

Admin felület

Valós idejű rendelés-lista, státuszkezelés, manuális tiltás lehetősége.

2 Szerepkörök

Négy szereplő vesz részt a rendszer működésében. Bejelentkezés csak az admin és futár szerepköröknél szükséges.

Szerepkör	Ki?	Hozzáférés	Azonosítás
Vendég	Fesztiválon tartózkodó látogató	QR → partnerválasztás → menü → kosár → rendelés leadás → e-mail megerősítés → rendelési szám megtekintés	E-mail + standkód
Partner Admin	A két étterem/stand üzemeltetője	Saját rendeléseik valós idejű listája · Rendelési státusz frissítés (Folyamatban / Kész / Kiszállítva) · Menü árak és tételek szerkesztése · Saját standjához futárokat felvehet / eltávolíthat	Google OAuth
Futár	A kiszállítást végző kollégák	Aktív, visszaigazolt rendelések megtekintése · Kiszállítás megjelölése · Standszám és rendelési szám látható · Felveheti: Rendszergazda (bármelyik standhoz) vagy Partner Admin (csak saját standjához)	Google OAuth
Rendszergazda	fejlesztő / üzemeltető	Teljes hozzáférés · Partner Adminok felvétele / eltávolítása · Futárok felvétele bármelyik standhoz · Rendelések törlése/tiltása · E-mail domain blacklist · Monitoring · Standkód lista szerkesztése	Google OAuth

Felhasználó-kezelés hierarchiája

Ki vehet fel kit — jogosultsági fa

Google OAuth — miért ez a legjobb választás

Nincs jelszókezelés, nincs jelszó reset flow, nincs „elfelejtett jelszó" email. A Rendszergazda meghívja a Partner Admin Google-fiókját, az egy kattintással bejelentkezik. A jogosultságok az adatbázisban tárolódnak (user_id → role + partner_id). Ha valaki kilép, egy törlés az adatbázisban azonnal megvonja a hozzáférést.

3 Folyamatábrák

3.1 — Fő vendégútvonal

Vendég rendelési folyamat — lépésről lépésre

3.2 — E-mail visszaigazolás folyamata

Visszaigazolási link kezelés — időzített token

3.3 — Admin / Futár munkafolyamat

Rendelés kezelési folyamat (admin + futár nézet)

4 Biztonsági rétegek — Visszaélés elleni védelem

⚠ Kritikus pont — Spam rendelés egyszer használatos e-maillel

A legfőbb fenyegetés: valaki egyszer használatos (10minutemail, guerrilla mail, stb.) e-mail fiókokat generál, rendeléseket ad le tömegesen ugyanarra a standra, visszaigazolja őket, és lekötözi a futárokat és a konyhát. Az alábbiakban 7 egymást erősítő védelmi réteget ismertetünk.

E-mail domain blacklist + MX rekord ellenőrzés Első vonal

Statikus blacklist: Ismert egyszer használatos szolgáltatók listájának fenntartása (10minutemail.com, guerrillamail.com, mailinator.com, yopmail.com, temp-mail.org, stb.) — nyílt forráskódú listák léteznek (pl. disposable-email-domains GitHub repo, 10 000+ domain).
MX rekord ellenőrzés: Ha az e-mail domain nem rendelkezik érvényes MX rekorddal, a rendelés elutasításra kerül. Ez kiszűri a teljesen nem létező domaineket.
Implementáció: Backend oldalon az e-mail beküldésekor (nem kliensoldal). DNS lookup: max. 1-2 mp késleltetés, elfogadható.
Korlát: Nem fogja ki az összes egyszer használatos domainent (folyamatosan jönnek újak). Ezért kell a többi réteg is.

IP alapú rate limiting Nagyforgalmú védelem

Szabály: Azonos IP-ről maximum 3 rendelési kísérlet / 1 óra. Ha eléri, a negyedik kísérlet blokkolva van.
Redis számláló: A saját infrastruktúrán futó Redis instance-on INCR + EXPIRE parancsokkal implementálva — egyszerű, nanoszekundumos válaszidő. Kulcs formátum: ratelimit:ip:{ip_hash}:{window}.
Kivétel kezelés: Mobilhálózati CGNAT esetén sok felhasználó osztja meg az IP-t — ezért nem lehet ez az EGYETLEN réteg. Kombinálni kell a többivel.
Visszajelzés: A felhasználó értesítő üzenetet kap: „Túl sok kérés erről az eszközről, kérjük próbáld meg 1 óra múlva."

E-mail alapú rate limiting — 1 aktív rendelés per cím Kulcsréteg

Szabály: Egyazon e-mail cím egyszerre csak 1 megerősítetlen rendeléssel rendelkezhet. Új rendelési kísérlet esetén a régi függő rendelés automatikusan érvénytelenítődik.
Megerősített rendelések: Visszaigazolt rendelés után ugyanarról az e-mail címről 45 percig nem lehet új rendelést leadni. (Ez az esemény valós tempójához igazított érték.)
Miért hatékony: Egyszer használatos e-mail esetén is csak egyetlen rendelést lehet leadni — a visszaigazolás után a cooldown érvényes. Több cím esetén az IP és a standkorlát véd.

Standkód alapú forgalomlimitálás Operációs védelem

Szabály: Egy adott standkódra maximum 5 aktív (megerősített, ki nem szállított) rendelés lehet egyidejűleg.
Miért: Ha valaki 30 rendelést ad le ugyanarra a standra, az tele tömné a futár listáját és a konyhát. Ez a korlát valós igényre van szabva (egy stand tipikusan 2-3 embert jelent).
Admin override: Az adminnak lehetősége van manuálisan megemelni egy stand limitjét (pl. csoportos rendelés esetén).
Fontos: Érvényes standkódok listája a rendszerben tárolódik — véletlenszerű kódot beírni nem fog működni.

Visszaigazolási token: egyszeri + rövid lejárat Megerősítési réteg

Token: 32 bájtos kriptográfiai biztonságú véletlen string — .NET-ben: RandomNumberGenerator.GetBytes(32) vagy Guid.NewGuid().
Lejárat: 15 perc. Ennyi alatt a fesztiválon könnyen meg lehet nyitni az e-mailt.
Egyszeri használat: A token aktiválás után azonnal érvénytelenítve van az adatbázisban.
Redirect URL: A megerősítő link egy dedikált végpontra mutat (/confirm?t=TOKEN), nem az alkalmazás főoldalára — megakadályozza a social engineering-et.

CAPTCHA / Honeypot mező Bot védelem

Ajánlott megközelítés: Ennél a forgalomnál (100-200 concurrent user) elegendő egy honeypot mező — egy rejtett input mező, amelyet valódi felhasználók nem töltnek ki, de automatizált botok igen. Ha ki van töltve → a rendelés silently eldobva.
Alternatíva: Google reCAPTCHA v3 (score alapú, nem zavarják a felhasználói élményt). Vagy Cloudflare Turnstile (ingyenes, adatvédelmileg barátságosabb).
Nincs szükség: reCAPTCHA v2 jelölőnégyzetre (lassítja a folyamatot, rossz UX fesztiválon). Az esemény idejére ez overkill lenne.

Admin monitoring + manuális tiltás Emberi felügyelet

Dashboard jelzők: Ha egy IP vagy e-mail domain rövid időn belül 3+ rendelési kísérletet tesz, az admin felületen automatikus figyelmeztetés jelenik meg.
Egyetlen gombnyomás: Az admin egy adott e-mail domainent vagy IP-t képes azonnali hatállyal tiltólistára helyezni.
Standkód manuális tiltás: Egy standkód ideiglenes kikapcsolása (pl. ha a stand kiköltözött onnan) — ez megszünteti az ide érkező rendelések lehetőségét.
Audit log: Minden rendelési kísérlet, blokkolás, manuális módosítás naplózásra kerül (IP, timestamp, email hash — nem szöveges e-mail).

Védelmi rétegek összefoglaló táblázata

Fenyegetés	Védelem	Hatékonyság
Ismert temp-mail domainről rendelés	Domain blacklist (réteg 1)	Magas (~80%)
Ismeretlen új temp-mail domainről	E-mail limit/cooldown (réteg 3) + standkorlát (réteg 4)	Magas
Tömeges automatizált rendelés (bot)	IP rate limit (réteg 2) + Honeypot (réteg 6)	Nagyon magas
Manuális spam (emberi)	Cooldown (réteg 3) + standkorlát (réteg 4) + monitoring (réteg 7)	Közepes-magas
Token újrahasználat	Egyszeri token + 15 perc lejárat (réteg 5)	Teljes

Tökéletes védelem nem létezik — de ez elég

A fesztiválon fizikailag ott kell lenni a QR kódhoz, a standkódhoz. Komoly, célzott támadás esetén (ami egy 4 napos gourmet feszten nem valószínű) az admin manuális beavatkozása mindig opció. A cél: a rendszer ne legyen triviálisan megtámadható, és legyen emberi felügyeleti lehetőség valós időben.

6 Technikai stack

A stack alapelve: ismert, kontrollált saját infrastruktúra, konténerizált futtatás, egyértelműen szétválasztott felelősségi körök. Nincs külső SaaS függőség az éles futtatáshoz.

Frontend — rendelési felület + admin panel

Next.js 15 (App Router) — SSR, RSC, gyors TTFB mobilon

Tailwind CSS v4 — utility-first, nincs runtime overhead

shadcn/ui — copy-paste komponensek, nulla bundle bloat, Radix UI alapú, akadálymentes

React 19 — Server Actions, use() hook, concurrent features

Backend — API réteg

.NET 10 — Minimal API vagy Controller alapú REST API

Entity Framework Core 10 — Code First, Migration-ok, PostgreSQL provider

ASP.NET Core Identity + Google OAuth (OpenID Connect) — szerepkör alapú hozzáférés

Hitelesítés

Google OAuth 2.0 / OpenID Connect — Partner Admin, Futár, Rendszergazda számára

NextAuth.js v5 — Google provider, JWT session, .NET API-val kommunikál

A Google OAuth flow: felhasználó bejelentkezik Google-lel → a backend ellenőrzi, hogy a Google sub (user ID) szerepel-e az app_users táblában és milyen szerepköre van → ha nincs bejegyezve, hozzáférés megtagadva. Így csak előre felvett személyek léphetnek be.

Adatbázisok

PostgreSQL 16 — fő relációs adatbázis, EF Core migration-ökkel kezelve

Redis 7 — rate limiting számlálók, token blacklist, session cache

E-mail küldés

AhaSend — tranzakciós e-mail, GDPR-barát, EU szerverek, dedikált IP opció

Saját SMTP — alternatíva, ha már van meglévő mail infrastruktúra (pl. Postfix + relay)

Visszaigazoló emailek küldése a .NET backend MailKit könyvtárán keresztül. Az email sablon HTML alapú, mobilon olvasható, minimális tartalom (token link + rendelési összesítő).

Konténerizáció és infrastruktúra

Docker — minden komponens saját container

Docker Compose — helyi fejlesztés + éles deploy egyforma konfiggal

Saját szerver / VPS — teljes kontroll, nincs külső függőség

Nginx — reverse proxy, SSL termination, statikus fájlok

PostgreSQL táblák vázlata (EF Core — Code First)

Tábla	Kulcs mezők	Megjegyzés
app_users	id, google_sub, email, role (enum), partner_id (nullable), created_by, created_at, is_active	Google OAuth azonosítóval kötött felhasználó. `partner_id` null = Rendszergazda. EF Core `HasConversion` a role enumhoz.
partners	id, name, description, logo_url, delivery_fee, is_active	A két partner stand adatai — admin szerkeszthető
orders	id, partner_id, stand_code_id, email_hash, email_encrypted, status (enum), order_number, confirmation_token, token_expires_at, total_price, created_at	Email kétféleképpen: hash (kereséshez/limithez), titkosítva (email küldéshez, AES-256). Token GUID, index: `status + created_at`.
order_items	id, order_id, menu_item_id, quantity, unit_price_snapshot	Árat snapshotolni kell (ne változzon utólag ha az admin módosít)
menu_items	id, partner_id, name, description, price, image_url, is_available, display_order	Partner Admin szerkesztheti valós időben, soft delete
stand_codes	id, code, label, is_active, active_order_count (computed/cached)	Érvényes standkódok listája — egyedi index a `code` oszlopra
blocked_domains	id, domain, added_at, added_by_user_id	Admin által szerkeszthető blacklist, FK az app_users-re
audit_log	id, event_type, ip_hash, email_hash, user_id (nullable), details (jsonb), created_at	GDPR-kompatibilis napló. Szöveges e-mail NEM kerül ide. `details` JSONB = rugalmas esemény adatok.

7 Fejlesztési ütemterv

Az esemény dátuma: 2025. június 4. Az alábbi ütemterv ~10 hetes fejlesztési ablakot feltételez. Priorizált: vendég felület → biztonsági logika → admin panel → tesztelés.

1–2. hét — Most

Tervezés és infrastruktúra setup

Rendszerterv véglegesítése · Docker Compose alap konfiguráció (Nginx, .NET API, Next.js, PostgreSQL, Redis) · EF Core DB séma + első migration · Google OAuth app regisztráció Google Cloud Console-ban · Menütartalom bekérése a partnerektől

3–4. hét

Frontend: vendég felület

Next.js 15 projekt setup + shadcn/ui komponensek · Partnerválasztó oldal · Menü + kosár UI (Server Components ahol lehet, Client ahol interakció kell) · Rendelési form (standkód + email + checkbox) · Visszaigazolási + rendelési szám oldalak · Mobile-first reszponzív

5. hét

Backend: rendelési logika (.NET 10)

Minimal API végpontok: POST /orders, GET /confirm/{token}, GET /orders/{orderNumber} · E-mail validáció (blacklist + MX DNS lookup) · MailKit integráció (AhaSend / SMTP) · Rendelési szám generátor (pl. prefix + timestamp + random) · Stand kód validáció · EF Core lekérdezések

6. hét — KRITIKUS

Biztonsági rétegek implementálása

IP rate limiting (Redis INCR/EXPIRE) · Email cooldown logika (Redis + PostgreSQL) · Stand limit logika · Honeypot mező (Next.js form) · Google OAuth middleware (.NET + NextAuth.js) · Szerepkör alapú hozzáférés (Partner Admin / Futár / Rendszergazda) · Audit log · Token lejárat + egyszeri használat — penetrációs teszt szemmel

7. hét

Admin és futár felület

Partner admin dashboard (Next.js, Google-bejelentkezés) · Rendelés lista + státuszfrissítés (realtime polling vagy SSE) · Futár nézet (egyszerűsített, csak aktív rendelések) · Menü szerkesztő · Domain blacklist UI · Felhasználó-kezelés: Rendszergazda felvesz Partner Admint + Futárt, Partner Admin felvesz Futárt (saját standhoz) · Monitoring jelzők

8. hét

Tesztelés + éles Docker deploy

End-to-end tesztelés valódi mobil eszközökön · Docker Compose éles konfiguráció (env változók, volume mount-ok, restart policy) · Nginx SSL konfiguráció (Let's Encrypt vagy saját cert) · Terhelés teszt (~200 concurrent kérés) · GDPR tájékoztató szöveg véglegesítése · E-mail sablonok mobilon tesztelve

9. hét — PUFFER

Hibajavítás + finomhangolás

Kötelező puffer hét! · Menü tartalom beillesztése (partnerektől beérkező végleges lista) · Ételfotók optimalizálása (WebP, lazy load, Next.js Image komponens) · EF Core migration-ök ellenőrzése éles DB-n · Staging szerveren teljes próba

10. hét (Esemény előtt 1 hét)

Éles üzembe helyezés

docker compose up -d éles szerveren · Stand kódok feltöltése · Google OAuth: Partner Admin + Futár Google-fiókok felvétele · Admin hozzáférések ellenőrzése · Monitoring (pl. egyszerű UptimeRobot ping) · QR kódok fizikai elhelyezése · Rövid oktatás: 15 perces walk-through a partnereknek és futároknak

⚠ Nem csúszhat — Kritikus határidők

Biztonsági rétegek (6. hét): Ha ez csúszik, az esemény biztonsági kockázatot jelent. Prioritás #1. | Google Cloud Console setup (1. hét): OAuth app regisztráció + authorized redirect URI-k beállítása — ez engedélyezési folyamat, akár napokat vehet igénybe! | Menütartalom (partnerektől): Legalább 3 héttel az esemény előtt kell a végleges menü + fotók. | AhaSend / SMTP konfiguráció: Domain hitelesítés (SPF, DKIM) beállítása — 24–48 óra propagáció. Nem hagyható utoljára.

8 Egyéb szempontok

Ételfotók kezelése

Ha 5-6 ételről 5-6 fotó kerül be: optimalizálás WebP formátumba, max 300 KB/fotó
Next.js beépített <Image> komponens: automatikus lazy loading, srcSet, AVIF/WebP konverzió
Statikus fájlok Nginx-en keresztül kiszolgálva (Docker volume) — nem a .NET API dolgozza fel
Éttermi logók feltétlenül kellenek (SVG formátum ajánlott, skálázható)

Offline / gyenge mobilnet kezelés

Next.js RSC (React Server Components): kevesebb JS a kliensen = gyorsabb betöltés gyenge neten
shadcn/ui: nincs runtime CSS-in-JS, statikus CSS = azonnali render
Form adatok localStorage-ban cache-elve (amíg el nem küldi) — nem veszik el kapcsolatmegszakadáskor
Visszaigazoló e-mail: bármikor megnyitható, online státusztól független

Teljesítmény (100–200 concurrent user)

.NET 10 Minimal API: az egyik leggyorsabb HTTP stack — a terhelést kényelmesen bírja egyetlen szerveren is
EF Core: compiled queries a frequently used lekérdezéseknél, no-tracking reads ahol nem kell change tracking
PostgreSQL indexek: email_hash, stand_code_id, status, created_at, confirmation_token
Redis connection pool: StackExchange.Redis alapértelmezett pool elegendő ennél a terhelésnél
Nginx: statikus fájlok gzip + cache headers, API kérések proxyolva

Kiszállítási díj kezelése

Kosárban fix összegként megjelenik a kiszállítási díj
Standkódtól függhet a díj (pl. közelebbi stand = alacsonyabb) — opcionális bonyolítás, eleinte fix díj egyszerűbb
Rendelési összesítőn jól láthatóan szerepel az összeg (amit majd a futárnak kell fizetni)