Uživatelská oprávnění/role

před 4 lety
lookass
Člen | 54
+
0
-

Ahoj, pracuji na vývoji firemního intranetu a mám dotaz nebo spíš prosbu, zda je někdo ochotný sdílet zkušenost s řízením uživatelských oprávnění.

Naše aplikace se skládá z vícero modulů. Do teď jsem uvažoval pouze metodu klasických uživatelských rolí (Guest, User, Master atd..) což mi moc nevyhovuje, protože pro každý modul je správcem jiný uživatel, v každém modulu má právo na zápis/editaci taktéž jiný uživatel, tzn. např. někdo může být administrátorem modulu 1, ale nemá právo zapisovat do modulu 2.

Po delším uvažování se kloním k řešení přibližně tímto způsobem:
Pro každý modul budou existovat role se specifiky daného modulu.
Př. Modul 1 bude mít hiearchické role: modul1-master, modul1-editor, modul1-canEditText, modul1-viewer. Modul 2: modul2-master, modul2-canDeleteItems, modul2-canEditItems, modul2-canCreateTasks, modul2-viewer.

Máte někdo nějaké jiné nápady nebo zkušenosti jak to řešit lépe? Děkuji za cokoliv.

před 4 lety
janpecha
Backer | 75
+
+2
-

Na jednom modulárním systému používáme následující:

  • každý uživatel má přiřazeno N rolí (role můžou být Admin (uživatel s přístupem všude), Fakturant (uživatel s přistupem jen do fakturace), apod., každý klient si je vytváří podle potřeb)
  • každá role má přiřazeno N oprávnění
  • oprávnění se skládá z ID zdroje a stupně přístupu
  • ID zdroje je řetězec ve tvaru modul.resource.action (např. admin.user.create, admin.userRole.delete, invoices.invoice.edit, apod.)
  • stupně přístupu máme aktuálně 3 (přístup zakázán, omezený přístup (=uživatel má přístup jen ke zdrojům, u kterých je nějakým způsoben veden jako „vlastník“), neomezený přístup) – defacto by ale stačilo i rozlišení „přístup povolen/přístup zakázán“

Navíc ID zdroje je hiearchické – takže v databázi lze přiřadit oprávnění třeba jen modulu admin nebo jen k admin.user a ostatní podřízené zdroje tohle oprávnění podědí. To se hodí třeba při skrývání položek v menu.

Authorizator pak nepoužíváme ten z Nette, ale máme vlastní třídu Authorizatoru, který používáme napříč systémem.

$authorizator->isAllowed('admin.user.create');
$authorizator->isAllowed('admin.user.edit', $userEntity);
$authorizator->isAllowed('admin.userRole.delete', $userRoleEntity);
// plus existuje metoda $authorizator->authorize() se stejnými parametry, která rovnou vyhazuje výjimku
před 4 lety
lookass
Člen | 54
+
0
-

@janpecha Mnohokrát děkuji za sdílení zkušenosti.

před 4 lety
Petr Steinbauer
Člen | 26
+
+1
-

V jednom z našich projektů jsme to realizovali takto:

Tedy velmi podobně jako janpecha

  • existují oprávnění na jednotlivé úkony
  • existuje administrace na pracovní role – zde se ale definuje co daná role může dělat
  • uživatel spadá do určité role
  • ta položka nadřazená role na obrázku se využívá jen pro vizualizace toho kdo je pod kým ve firemní hiearchii, na obrázku je tedy zavádející :)

Zkušenosti s používáním:
Občas je náročné všechny oprávnění ohlídat – například „může mazat, když nemůže číst?“ – když toto pomineme, tak kromě extrému kdy má zákazník třeba 30 rolí, je toto řešení plně funkční – zákazníci si sami nastavují role a co má daný pracant na starosti. Díky tomu že role odpovídají reálným pracovním rolím ve firmě, nevolají že by jim něco nebylo jasné :)