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.
56 lines
1.9 KiB
Lua
56 lines
1.9 KiB
Lua
BleeterPermissions = {}
|
||
|
||
local feedPostRights = {
|
||
private = { home = true },
|
||
small_business = { advertising = true },
|
||
company = { advertising = true },
|
||
authority = { home = true, advertising = true },
|
||
lifeinvader = {}
|
||
}
|
||
|
||
function BleeterPermissions.CanPost(profileType, feedType)
|
||
local rights = feedPostRights[profileType or ''] or {}
|
||
return rights[feedType or ''] == true
|
||
end
|
||
|
||
function BleeterPermissions.CanInteract(profile)
|
||
return profile and profile.is_locked ~= true and profile.is_active ~= false
|
||
end
|
||
|
||
--- Anbieterrechte (Lifeinvader).
|
||
---
|
||
--- Erste Quelle ist die Anmeldung am PC: wer als admin@liveinvader.ls
|
||
--- angemeldet ist, hat alle Rechte. Damit haengt Bleeter an derselben Stelle
|
||
--- wie das Webhosting, statt eine zweite Rechteliste zu fuehren.
|
||
---
|
||
--- Die alte Tabelle bleibt als zweiter Weg bestehen – der Notausgang, falls
|
||
--- ic-web einmal nicht laeuft.
|
||
function BleeterPermissions.HasLifeinvaderPermission(source, permission)
|
||
if IcWebAdapter and IcWebAdapter.IsProvider(source) then
|
||
return true
|
||
end
|
||
|
||
if SuperPcAdapter and SuperPcAdapter.HasLifeinvaderPermission then
|
||
return SuperPcAdapter.HasLifeinvaderPermission(source, permission)
|
||
end
|
||
return false
|
||
end
|
||
|
||
--- Darf diese Person die Mitglieder dieses Profils verwalten?
|
||
--- Der Anbieter immer; sonst nur, wer im Profil ausdruecklich dafuer
|
||
--- eingetragen ist. Wer nur posten darf, soll sich nicht selbst weitere
|
||
--- Rechte holen koennen.
|
||
function BleeterPermissions.CanManageMembers(source, charId, profileId)
|
||
if BleeterPermissions.HasLifeinvaderPermission(source, 'profile.staff') then
|
||
return true
|
||
end
|
||
if not charId or charId == '' or not profileId then return false end
|
||
|
||
local row = MySQL.single.await([[
|
||
SELECT 1 AS ok FROM bleeter_profile_members
|
||
WHERE profile_id = ? AND char_id = ? AND can_manage_members = 1
|
||
LIMIT 1
|
||
]], { profileId, charId })
|
||
|
||
return row ~= nil
|
||
end
|