Bjoern Flessing
20076b0aee
Jeder Spieler waehlt sich ein Handle mit @, Unternehmen und Behoerden bekommen
eigene Profile, fuer die sie Mitarbeiter freigeben.
Verwaltet wird ueber dieselbe Anmeldung wie das Webhosting: wer am IC-Computer
als Anbieter angemeldet ist, richtet Unternehmensprofile ein. Damit gibt es
genau eine Stelle, an der Verwaltungsrechte haengen - ein zweites Rechtesystem
daneben waere eine zweite Stelle, an der man jemanden zu entziehen vergisst.
Bewusst getrennt: wer fuer ein Unternehmen schreiben darf, kann sich nicht
selbst zum Verwalter machen.
Behoben gegenueber dem Ausgangsstand:
- Die Resource startete nicht. Eine harte Abhaengigkeit zeigte auf eine
Resource, die es nicht gibt - das verhindert den Start vollstaendig.
- Das Schema war gegenueber dem Code stehengeblieben: eine Tabelle fehlte
ganz, sechs Spalten fehlten. Jede Registrierung eines Handles scheiterte
deshalb mit einem SQL-Fehler. Zwei Migrationen ziehen das nach.
- Die Identitaet kommt jetzt von ESX statt von einem Charaktersystem, das
hier nicht laeuft. Ohne das findet das Mailsystem die Postfaecher nicht.
- Das Fenster hatte keinen Schliessknopf, nur ESC. Im Computerfenster ist
diese Taste aber schon vergeben.
- Bilder laden mit referrerpolicy="no-referrer": Bilderdienste sperren
Hotlinks anhand der Herkunft, und die eines NUI kennen sie nicht.
- Der Schluessel fuer den Bilder-Upload steht nicht mehr im Code, sondern in
der server.cfg (set bleeter_imgbb_key). Er gehoert nicht in ein oeffentlich
einsehbares Repository.
Neu: Unternehmensprofile und Mitarbeiterfreigabe, ueber Netzwerkereignisse und
Konsolenbefehle. Dazu eine Oberflaeche im IC-Computer, die dieselbe Gestaltung
benutzt - die Stildatei wird dafuer mechanisch gekapselt, statt sie nachzubauen.
Enthaelt README.md mit Einrichtung, Rechten und den Fallstricken.
46 lines
2.1 KiB
Lua
46 lines
2.1 KiB
Lua
-- ─────────────────────────────────────────────────────────────────────────────
|
||
-- Bleeter ← ic-web
|
||
--
|
||
-- Bleeter wird ueber dieselbe Anmeldung verwaltet wie das Webhosting: wer am
|
||
-- PC als admin@liveinvader.ls angemeldet ist, ist auch hier der Anbieter.
|
||
--
|
||
-- Damit gibt es genau eine Stelle, an der Anbieterrechte haengen – ein
|
||
-- zweites Rechtesystem daneben waere eine zweite Stelle, an der man jemanden
|
||
-- vergessen kann zu entziehen.
|
||
--
|
||
-- Anbieter (superadmin) richtet Unternehmensprofile ein und verwaltet sie
|
||
-- Unternehmen geben eigene Leute fuer ihr Profil frei
|
||
-- Spieler waehlen ihr eigenes Handle mit @
|
||
--
|
||
-- Die alte Tabelle bleeter_lifeinvader_permissions bleibt als zweiter Weg
|
||
-- bestehen: sie ist der Notausgang, falls ic-web einmal nicht laeuft.
|
||
-- ─────────────────────────────────────────────────────────────────────────────
|
||
|
||
IcWebAdapter = {}
|
||
|
||
--- Anmeldung am PC, falls vorhanden.
|
||
---@return table|nil { username, role, domain, ... }
|
||
function IcWebAdapter.GetSession(source)
|
||
if GetResourceState('ic-web') ~= 'started' then return nil end
|
||
|
||
local ok, session = pcall(function()
|
||
return exports['ic-web']:GetSession(source)
|
||
end)
|
||
return ok and session or nil
|
||
end
|
||
|
||
--- Ist diese Person gerade als Anbieter angemeldet?
|
||
function IcWebAdapter.IsProvider(source)
|
||
local session = IcWebAdapter.GetSession(source)
|
||
return session ~= nil and session.role == 'superadmin'
|
||
end
|
||
|
||
--- Ist diese Person fuer eine Domaene angemeldet – also Sprecher einer Stelle?
|
||
--- Wird nicht fuer Rechte benutzt, sondern nur als Vorschlag beim Einrichten
|
||
--- eines Unternehmensprofils.
|
||
---@return string|nil Domaene, wenn angemeldet
|
||
function IcWebAdapter.SessionDomain(source)
|
||
local session = IcWebAdapter.GetSession(source)
|
||
if not session then return nil end
|
||
return session.domain
|
||
end
|