PPNP Game – Login-Brücke

Das Modul stellt eingeloggten Nutzern ein kurzlebiges, signiertes JWT aus, mit dem sich der separate Node.js-Spieldienst (ppnp.weinify.de/game) authentifiziert. Es gibt keinen eigenen Login-Nachbau – der Node-Dienst prüft nur die Signatur und vertraut WordPress als Identitätsquelle.

Allgemein

Spielstart per Button

Ein Shortcode zeigt einen „Spiel starten“-Button für eingeloggte, freigeschaltete Nutzer. Ein Klick holt per AJAX ein frisch signiertes Token und leitet direkt zum Node.js-Spieldienst weiter, der das Token aus dem URL-Fragment liest.

Drei getrennte Spiel-Berechtigungen

Neben der reinen Spielfreigabe (view-Recht über die normale Modulberechtigung) gibt es drei eigene, im Nutzerprofil einzeln vergebbare Capabilities: Stammdaten pflegen (Typen, Attacken, Pyxlinge), neue Welten erstellen und den Beta-Bereich verwalten. Editoren und Administratoren erhalten die ersten beiden automatisch über ihre Rolle, die Beta-Berechtigung bewusst nur Administratoren.

Spielerliste für den Node-Dienst

Der Node-Dienst kann per authentifiziertem Callback die vollständige Liste aller fürs Spiel freigeschalteten Nutzer abrufen – Grundlage für die Spieler-Zuweisung pro Welt im Spieldienst selbst.

Shortcodes

Shortcode	Beschreibung
weinhold_ppnp_game_launch	Button für eingeloggte, freigeschaltete Nutzer, der ein signiertes Spiel-Login-Token holt und zum Node.js-Spiel weiterleitet. Keine Parameter

Dateien

modules/ppnp_game_auth.php – einzige Datei des Moduls: Capability-Verwaltung, JWT-Signierung, AJAX-Endpunkte (Token-Ausstellung, Spielerliste), Shortcode, Admin-Statusseite, Cleanup.

Für Entwickler

Kein eigener Datenbank-State

Anders als fast alle anderen Module gibt es kein maybe_install() und keine eigene Tabelle: Das Modul signiert bei jedem Aufruf nur ein kurzlebiges Token aus bereits vorhandenen WordPress-Nutzerdaten. weinhold_ppnp_game_auth_cleanup() existiert trotzdem, weil die drei Capabilities echter, dauerhafter State sind, der beim Zurücksetzen sauber von allen Rollen UND individuell zugewiesenen Nutzern entfernt werden muss.

Selbst gebautes HS256-JWT ohne Bibliothek

weinhold_ppnp_game_auth_sign_token() baut das JWT von Hand (Base64url-Encoding, HMAC-SHA256-Signatur über hash_hmac()) statt eine Composer-Bibliothek einzubinden – der Node-Dienst validiert nur die Signatur mit demselben Secret (PPNP_GAME_JWT_SECRET aus der wp-config.php), es findet keine eigene Session-Verwaltung im Spieldienst statt. Das Token trägt neben der Nutzer-ID auch die drei Capability-Flags direkt im Payload und läuft nach 120 Sekunden ab – bewusst nur als kurzlebiges Sprungbrett zum Aufbau der WebSocket-Verbindung gedacht, nicht als dauerhaftes Zugangs-Credential.

Server-zu-Server per Shared Secret

Der Callback für die Spielerliste läuft über einen nopriv-Ajax-Hook (der Node-Dienst hat keine WordPress-Session) und wird stattdessen über ein zweites, vom JWT-Secret getrenntes Shared Secret abgesichert (Header X-PPNP-Game-Secret, Konstante PPNP_GAME_API_SECRET, Vergleich per hash_equals() gegen Timing-Angriffe). Die Freigabeprüfung nutzt exakt dieselbe Funktion wie beim Token-Ausstellen, damit „wer darf spielen“ nur eine einzige Quelle der Wahrheit hat.

Besonderheiten

Dieses Modul ist das dokumentierte Vorbild für den MCP-Server-Manager: Beide nutzen signierte Tokens, ein zweites Shared Secret für Server-zu-Server-Calls und Capability-basierte statt tabellenbasierte Zugriffsrechte. Der MCP Server Manager weicht bewusst in zwei Punkten ab (dynamische statt fester Capabilities, langlebige statt kurzlebige Tokens) – wer den Aufbau des einen Moduls versteht, erkennt die Struktur des anderen sofort wieder.

Zwei komplett getrennte Secrets für zwei komplett getrennte Zwecke: PPNP_GAME_JWT_SECRET signiert Nutzer-Tokens, PPNP_GAME_API_SECRET schützt den Server-zu-Server-Callback – ein kompromittiertes Secret legt nie beide Kanäle gleichzeitig offen.

Die Beta-Berechtigung wird absichtlich NICHT wie die anderen beiden Capabilities automatisch an Editoren vergeben, obwohl der Code dafür identisch aufgebaut ist – reine Vorsichtsmaßnahme, damit ein unfertiger Beta-Bereich nicht versehentlich für alle Spielleiter sichtbar wird.

Versionshistorie

Version	Datum	Änderung
1.0.0	22.09.2026	Einführung der Versionierung.

PPNP Game – Login Bridge

The module issues logged-in users a short-lived, signed JWT used to authenticate against the separate Node.js game service (ppnp.weinify.de/game). There is no reimplementation of login — the Node service only verifies the signature and trusts WordPress as the identity source.

General

Launching the Game via a Button

A shortcode shows a „Start game“ button for logged-in, authorized users. Clicking it fetches a freshly signed token via AJAX and redirects straight to the Node.js game service, which reads the token from the URL fragment.

Three Separate Game Permissions

Besides plain game access (the view right via the normal module permission), there are three dedicated capabilities, individually assignable in the user profile: managing master data (types, moves, Pyxlinge), creating new worlds, and managing the beta area. Editors and administrators get the first two automatically through their role; the beta permission is deliberately given only to administrators.

Player List for the Node Service

The Node service can fetch the full list of users authorized to play via an authenticated callback — the basis for assigning players to worlds within the game service itself.

Shortcodes

Shortcode	Description
weinhold_ppnp_game_launch	Button for logged-in, authorized users that fetches a signed game login token and redirects to the Node.js game. No parameters

Files

modules/ppnp_game_auth.php – the module’s only file: capability management, JWT signing, AJAX endpoints (token issuance, player list), shortcode, admin status page, cleanup.

For Developers

No Database State of Its Own

Unlike almost every other module, there is no maybe_install() and no dedicated table: the module simply signs a short-lived token from existing WordPress user data on every call. weinhold_ppnp_game_auth_cleanup() still exists because the three capabilities are real, persistent state that must be cleanly removed from all roles AND individually assigned users on reset.

A Hand-Rolled HS256 JWT, No Library

weinhold_ppnp_game_auth_sign_token() builds the JWT by hand (base64url encoding, HMAC-SHA256 signature via hash_hmac()) instead of pulling in a Composer library — the Node service only validates the signature with the same secret (PPNP_GAME_JWT_SECRET from wp-config.php); there is no separate session management in the game service. The token carries the three capability flags directly in the payload alongside the user ID and expires after 120 seconds — deliberately just a short-lived stepping stone for bootstrapping the WebSocket connection, not a lasting access credential.

Server-to-Server via Shared Secret

The player-list callback runs through a nopriv Ajax hook (the Node service has no WordPress session) and is instead secured with a second shared secret, separate from the JWT secret (header X-PPNP-Game-Secret, constant PPNP_GAME_API_SECRET, compared with hash_equals() against timing attacks). The authorization check uses the exact same function as token issuance, so „who may play“ has only a single source of truth.

Special Cases

This module is the documented template for the MCP Server Manager: both use signed tokens, a second shared secret for server-to-server calls, and capability-based rather than table-based access rights. The MCP Server Manager deliberately diverges in two ways (dynamic instead of fixed capabilities, long-lived instead of short-lived tokens) — understanding this module’s structure makes the other module’s structure immediately recognizable.

Two completely separate secrets for two completely separate purposes: PPNP_GAME_JWT_SECRET signs user tokens, PPNP_GAME_API_SECRET protects the server-to-server callback — a compromised secret never exposes both channels at once.

The beta permission is deliberately NOT granted automatically to editors like the other two capabilities, even though the code for it is structured identically — a pure precaution so an unfinished beta area doesn’t accidentally become visible to every game master.

Version History

Version	Date	Change
1.0.0	22.09.2026	Introduction of versioning.

ppnp-game-auth