fix rewards and bypass ip limits

README.md

@@ -27,6 +27,12 @@ und Game-Server. Bei späteren Starts überspringt sich der Seed selbst.
 [Zum Entwickeln]“** klicken, E-Mail + Passwort eingeben. Danach Charakter
 erstellen und auf den Charakter klicken – man landet direkt im Spiel.
 
+**Charakter Limits anheben** Folgendes Kommando setzt für alle existierenden Spieler das Charakter Limit auf 18.
+```sh
+docker compose exec al-mongo mongosh adventureland --eval \
+  'db.user.updateMany({}, { $set: { "info.slots": 18 } })'
+```
+
 **Admin werden:** Die Admin-Seiten (`/admin/executor`, `/admin/renderer`) sind
 standardmäßig gesperrt. `is_admin` in `common/admin.js` prüft das Feld
 `user.admin`; setzen lässt es sich direkt in MongoDB:
@@ -40,6 +46,37 @@ Alternativ in `config/options.js` `unsecure_admin: true` setzen – dann gilt
 **jeder** Besucher als Admin (`/admin/executor` erlaubt Code-Ausführung), daher
 nur bei rein lokalem Zugriff sinnvoll.
 
+**GM werden (Game):** Der Web-Admin ist **kein** Game-GM. Die GM-Rolle hängt am
+Charakter, nicht am Benutzerkonto: Der Game-Server prüft `player.role` bzw.
+`player.p.role` auf `"gm"`. Charakter vorher ausloggen, dann in MongoDB setzen:
+
+```sh
+docker compose exec al-mongo mongosh adventureland --eval \
+  'db.character.updateOne(
+    { name: "CharName" },
+    { $set: { role: "gm", "info.p.role": "gm" } }
+  )'
+```
+
+Danach den Charakter neu einloggen. `role: "gm"` gibt die In-Game-GM-Rechte und
+ist unabhängig von `user.admin` (Web-Admin). Wer **nur** von den Multi-Account-
+Limits ausgenommen werden will, aber keine GM-Rechte braucht, setzt stattdessen
+`info.p.free`:
+
+```sh
+docker compose exec al-mongo mongosh adventureland --eval \
+  'db.character.updateOne(
+    { name: "CharName" },
+    { $set: { "info.p.free": true } }
+  )'
+```
+
+| Feld | Wirkung |
+| --- | --- |
+| `user.admin: true` | Web-Admin: `/admin/executor`, `/admin/renderer`; keine In-Game-GM-Rechte |
+| Charakter `role: "gm"` | In-Game-GM; wird außerdem von den Limits ausgenommen |
+| Charakter `info.p.free: true` | nur Limit-Ausnahme; keine GM-Rechte |
+
 ## Aufbau
 
 | Service      | Image               | Aufgabe                                                       |
@@ -61,7 +98,8 @@ ersetzt das Template aus dem Upstream-Repo:
 - `config/keys.js` – MongoDB-URI, Master-Keys, Stripe/Steam/SES (alles leer bzw.
   feste Entwicklungs-Defaults). Die Werte sind absichtlich stabil, damit
   Sitzungen und Serverdatensätze Neustarts überleben.
-- `config/options.js` – `base_url`, Ports, Serverdefinition `local`.
+- `config/options.js` – `base_url`, Ports, Serverdefinition `local`,
+  Multi-Account-Limits.
 
 Beide Dateien sind normale Node-Module; nach Änderungen Container neu starten:
 
@@ -73,6 +111,39 @@ docker compose restart backend game
 > `docker-compose.yml` (`ports`), `config/options.js` (`port`, `local_port`,
 > `address`) und `base_url` (inkl. Port).
 
+### Multi-Account-Limits
+
+`config/options.js` steuert, wie viele Charaktere gleichzeitig online sein
+dürfen:
+
+| Option | Bedeutung | aktuell |
+| --- | --- | --- |
+| `ip_limit` | Nicht-Händler pro IP (mal `ipx` einer IP-Ausnahme) | `9` |
+| `character_limit` | Nicht-Händler pro Konto | `3` |
+| `merchant_ip_limit` | Händler pro IP | `3` |
+| `merchant_owner_limit` | Händler pro Konto | `1` |
+
+Die Werte gelten beim Login (`is_player_allowed`) und im Backend-Cron
+(`enforce_limitations`). Der Patch
+`docker/patch-multi-account-limits.js` ersetzt dabei die früher fest codierten
+Grenzen (3 Nicht-Händler, 1 Händler). Mit den aktuellen Werten können z. B. drei
+Konten von derselben IP jeweils drei Nicht-Händler-Charaktere online haben
+(9 insgesamt); ein zehntes Nicht-Händler-Charakter bzw. ein vierter Händler wird
+abgewiesen. `character_limit` ist die Zahl der **gleichzeitig online** erlaubten
+Charaktere, nicht die Zahl der Charakterplätze (`info.slots`); `ip_limit` ist
+ebenfalls keine Slotzahl. Eine `IP_<ip>`-Ausnahme mit
+`{ exception: true, info: { limit: N } }` multipliziert nur `ip_limit` für
+Nicht-Händler, nicht die Händler-Limits. Nicht-freie Händler zählen; `p.free`
+und GM-Charaktere fallen heraus. `merchant_owner_limit: 1` erlaubt einen Händler
+pro Konto; Admin- und User-Händler auf getrennten Konten sind damit kein
+Problem. Sollen beide auf **demselben** Konto laufen, `merchant_owner_limit` auf
+`2` setzen.
+
+> Hinter einem Reverse-Proxy (Caddy) muss die echte Client-IP als
+> `X-Forwarded-For` ankommen. Sonst sieht der Server nur die Proxy-/Docker-IP
+> und alle Spieler teilen sich dieselben Limits. Siehe
+> `deploy/Caddyfile.example`.
+
 ### MongoDB-Zugriff
 
 Die Datenbank ist nur im Compose-Netz erreichbar. Für einen Blick hinein:
@@ -145,6 +216,21 @@ Login als verifiziert und überspringt die Verifikationsmail. Ohne den Schalter
 bleibt das Upstream-Verhalten unverändert. Auch dieser Patch bricht den Build
 ab, wenn ein Anker in `api.js` fehlt.
 
+`docker/patch-tutorial-reward-auth.js` macht die `auth_id`-Pflicht der
+Tutorial- und Klassenbelohnungen abschaltbar. Bei
+`options.tutorial_reward_requires_auth_id: false` können auch reine Web-Accounts
+`c0` und Klassenbelohnungen abholen; fehlt die Option oder steht sie auf `true`,
+gilt das Upstream-Verhalten. Fehlt einer der beiden Anker in `node/server.js`,
+bricht der Build ab.
+
+`docker/patch-multi-account-limits.js` macht die Händler- und Nicht-Händler-
+Limits konfigurierbar. Upstream prüft beim Login `options.ip_limit` und
+`options.character_limit`, würgt im Backend-Cron aber pauschal nach 3
+Nicht-Händlern bzw. 1 Händler ab. Der Patch liest beide Stellen aus
+`config/options.js` (`ip_limit`, `character_limit`, `merchant_ip_limit`,
+`merchant_owner_limit`). Fehlt ein Anker in `node/server_functions.js` oder
+`adventure_functions.js`, bricht der Build ab.
+
 ## Spieldaten anpassen (`files/custom/game.js`)
 
 Werte bestehender Elemente und neue Elemente lassen sich ohne Quelltextänderung
@@ -207,15 +293,17 @@ Custom-Datei zurückgesetzt werden; dann den Game-Server neu starten.
   auf `true` setzen (siehe Admin-Befehl oben). Die `/ev`-Route bleibt in beiden
   Fällen funktionsfähig.
 
-- **Tutorial-Belohnung (`c0`):** Jedes Konto mit `auth_id` (Steam/MAS) kann nach
+- **Tutorial-Belohnung (`c0`):** Jedes verifizierte Konto kann nach
   abgeschlossenem Tutorial einmal `c0` abholen. Die Belohnung ist ein zufälliger
   kosmetischer Look aus dem `cosmo0`-Pool (über 100 Varianten). Der Game-Server
-  prüft dafür `player.verified` **und** `player.auth_id`
-  (`node/server.js:5272`). Bei reinen Web-Accounts ohne Steam/MAS bleibt
-  `auth_id` leer, deshalb ist die Belohnung trotz Auto-Verifizierung weiterhin
-  gesperrt. Die alten Klassen-Belohnungen (`creward`) sind in
-  `design/classes.js` auskommentiert und werden vom Client nicht angefragt;
-  Hardcore-Rewards gelten nur auf dem Hardcore-Server.
+  prüft `player.verified` und normalerweise `player.auth_id` (Steam/MAS,
+  `node/server.js`, `ureward`/`creward`). Bei reinen Web-Accounts ist `auth_id`
+  leer; deshalb steht `options.tutorial_reward_requires_auth_id` hier auf
+  `false`, damit auch sie die Belohnung erhalten. Auf `true` gestellt, gilt
+  wieder die Upstream-Sperre für Web-Accounts. Die alten Klassen-Belohnungen
+  (`creward`) nutzen denselben Schalter, sind aber in `design/classes.js`
+  auskommentiert und werden vom Client nicht angefragt; Hardcore-Rewards gelten
+  nur auf dem Hardcore-Server.
 
 - **„Authorization Failure“ (Gold/Glück −85 %, XP −20 %):** Das ist die
   DRM-Prüfung des Game-Servers. Sie verlangt für jedes Konto ab 2019 eine