Open Gestionale
DemoUn gestionale web universale per server roleplay: API bridge Node.js sul VPS + frontend React su CDN. Carica il layout dall'API e renderizza widget modulari. Non conosce nessuna ambientazione: sa solo che esistono giocatori, dati e widget — cosa mostrano lo decide la config del server.
Non conosce l'ambientazione
Stesso test degli altri moduli: funzionerebbe identico su un server fantasy medievale? La risposta è in examples/fantasy/: lo stesso identico codice del realistico, cambiano solo gestionale.yml e layout.yml. I widget economy.* e identity.* spariscono da soli perché i loro moduli non sono attivi — nessuna riga toccata.
auth · config · widget REST · OpenAPI
Read-mostly: il gestionale legge i dati di gioco e scrive solo sulle proprie tabelle (sessioni, OTP, notizie, stato notifiche). L'integrità del gioco resta protetta.
Il layout è una risposta dell'API
Al login il frontend chiama GET /config/layout e riceve un layout già risolto per quel giocatore: i widget il cui modulo non è attivo, o per cui manca la capability, sono già stati tolti e i tab vuoti eliminati. Il frontend renderizza ciò che riceve e non sa quali moduli esistano.
Niente password: identità dal gioco
Il gestionale non ha un proprio sistema di credenziali. Il giocatore digita /gestionale login in gioco, riceve un codice a 6 cifre (OTP, valido 5 minuti, monouso) e lo inserisce nel pannello. L'API emette un JWT che porta solo l'UUID: grado e capability vengono riletti dal DB a ogni richiesta, così una promozione in gioco si riflette al refresh.
- OTP generato dal plugin Paper, hash legato all'UUID, scade e si invalida dopo l'uso
- JWT firmati con la chiave dell'admin; l'avvio in produzione rifiuta il placeholder
- Rate limiting su auth (per IP) e API (per token); HTTPS obbligatorio fuori dallo sviluppo
- I permessi rispecchiano quelli dei plugin: nessun modello di ruoli separato
Moduli e widget
I widget crescono con i moduli Open Roleplay installati. core è sempre presente; gli altri si attivano in modules.active.
| Modulo | Widget | Visibile a |
|---|---|---|
core | profilo, tempo settimanale, notifiche, notizie | tutti |
economy | bilancio, transazioni, carte, bonifico | tutti |
companies | le mie aziende, dettaglio, registro pubblico | tutti / membri |
openfdo | casellario, fascicoli, ricercati, foglio di servizio | tutti / FDO via capability |
politics | cariche, leggi, elezioni, decreti | tutti |
jobs | lavoro attuale, storico, offerte | tutti |
health | cartella clinica, appuntamenti | tutti |
identity | documenti, telefono | tutti |
education | titoli di studio, corsi | tutti |
Demo con dati fittizi
Niente da installare per capire cosa fa: la demo gira con un seed di dati fittizi e nessun login. Scegli un profilo e vedi widget diversi in base al ruolo — è lo stesso meccanismo di permessi del gioco.
git clone https://github.com/giovyx90/open-roleplay
cd open-roleplay/open-gestionale
docker compose up --build
# API: http://localhost:3000 — Frontend: http://localhost:8080Deployment
Due progetti indipendenti. Il frontend è statico: gira su qualsiasi CDN (spesso gratis) e viene servito dall'edge, vicino ai giocatori. L'API resta sul VPS, vicina al DB.
- Frontend su Vercel / Netlify / Cloudflare Pages con
VITE_API_URLverso il bridge - API sul VPS dietro reverse proxy TLS, con accesso al DB di Open Roleplay
- CORS configurato in
gestionale.ymlcon la lista dei domini frontend - Un'istanza per server: i dati dei giocatori non escono mai dal server del gestore
Cosa non fa mai
- Non modifica i dati di gameplay (il bonifico è simulato in demo, in produzione richiede un adapter dedicato)
- Non ha un sistema di permessi proprio: legge le capability dal DB e le rispetta
- Non assume nessuna ambientazione: nomi e struttura vengono dalla config
- Non crasha se un modulo manca: mostra il widget "non disponibile"
- Non richiede un account separato: l'identità passa dal server Minecraft
- Nessun telemetry, nessun analytics esterno