Vylepšené/Upravené ACL …

Upozornění: Tohle vlákno je hodně staré a informace nemusí být platné pro současné Nette.
před 14 lety
Peter9
Člen | 69
+
0
-

Príde mi zbytočné písať (tým myslím, že koncept je dobrý, ale pre väčšie projekty je to dosť nemotorné) pre každú skupinu ľudí nejaké práva – čo smú a čo nie napr. „BackEnd:Default“, „BackEnd:Default:edit“ a pod.
Preto rozmýšľam nad niečim takýmto:

Vytvoriť tabuľku „groupe(s)“, ktorá bude mať 4 levely (guest, user, special, admin)
Tabuľka:

+-----+-------+-------+-------+-------+-------------+
| gid | lvl_g | lvl_u | lvl_s | lvl_a |     name    |
+-----+-------+-------+-------+-------+-------------+
|  1  |   0   |   0   |   0   |   0   |    banned   |
+-----+-------+-------+-------+-------+-------------+
|  2  |   1   |   0   |   0   |   0   |    guest    |
+-----+-------+-------+-------+-------+-------------+
|  3  |   1   |   8   |   0   |   0   |    user     |
+-----+-------+-------+-------+-------+-------------+
|  4  |   1   |   8   |   5   |   0   |    editor   |
+-----+-------+-------+-------+-------+-------------+
|  5  |   1   |   8   |   8   |   5   |    admin1   |
+-----+-------+-------+-------+-------+-------------+
|  6  |   1   |   8   |   8   |   8   |    root     |
+-----+-------+-------+-------+-------+-------------+

SQL:

TABLE "groupes" (
    `gid` INT(5) UNSIGNED NOT NULL PRIMARY AUTO_INCREMENT,
  `lvl_g` TINYINT(1) DEFAULT `1`,
  `lvl_u` TINYINT(3) UNSIGNED DEFAULT `0` ,
  `lvl_s` TINYINT(3) UNSIGNED DEFAULT `0` ,
  `lvl_a` TINYINT(3) UNSIGNED DEFAULT `0` ,
   `name` VARCHAR(50) NOT NULL
)

Pričom budem verifikovať usera pomocou týchto štyroch prístupových práv (guest môže mať iba 2 stavy: povolený/nepovolený (prístup na stránku bude napr. na žiadosť), user môže mať 8 stupňov(pričom 8 je bežný user, user s nulou – zablokovaný prístup userovi, atp.))…

Authenticator by vyzeral asi takto nejako

class myAuth extends Object implements IAuthenticator
{
     public function authenticate(array $credentials)
     {
	 $user = dibi::fetch('SELECT * FROM user LEFT JOIN groupes ON user.rightsId = groupes.id');

	 // overenie mena, hesla

	 $identity = new Identity($user->id, $user->groupeName);
	 $identity->name = $user->name;
	 return $identity;
     }
}

…Ešte som nerozmysel čo a ako s templatmi ale asi takto nejako:

{$user->isAdmin}
 ....
{$user->isEditor}
 ....
{$user->isMember}
 ....
{$user->isGuest}
 ....

A Resources by sa chránili sami (metódou authenticate(názov nezáleží) v metóde startup v base presenteri)…
Nie je to lepšie ako foreach-ovať veľa resources?

Chcem počuť váš zdrvujúci názor :) Čo by som mal zlepšiť :)

před 14 lety
paranoiq
Člen | 392
+
0
-

autentizace podle levelů je vždycky špatně. a je jedno, že není jeden žebříček, ale hned čtyři. časem se najde role, která prostě do žebříčku levelů pasovat nebude.
uživatel bude potřebovat na jednom místě Admin level 7 a na jiném nebude smět přistupovat ke zdroji s Admin level 5.

navíc číslo neříká nic o tom, jakou akci vlastně může či nemůže provádět a přidělování levelů akcím tak bude více méně ad-hoc. a to bezpečnosti moc nepomůže

a proč vlastně zrovna 8?! (tedy číslo 8 mám rád, ale má jeho použití nějaký opodstatněný základ, nebo je to prostě jen nějaké hausnumero?)

Editoval paranoiq (17. 2. 2011 15:35)

před 14 lety
Peter9
Člen | 69
+
0
-

hai, hausnumero :D …to mi len tak napadlo, ptže aj ja si myslím, že je to pekné číslo.

Poznáš Magento?

Ako je to tam riešené? Je to obrovský e-shop systém (60MB) postavený na Zende, databáza má 377 tabuliek…Administrácia je obrovská (je v tom veľa presenterov a viewov)…Ak by mali tam riešiť to, ktorej skupine sa čo má zobraziť a čo nie pomocou vymenúvania, tak by to bolo obrovský problém…

Skupín ani veľa byť nemusí, ide o to, či vymenúvať všetky presenteri, vieweri je dobrá vec…

Nech je 10 skupín na 250 presenterov, každý má 6 views – tak to dá zabrať aj Nette…

před 14 lety
Peter9
Člen | 69
+
0
-

alebo nejak nastaviť výnimky…

napríklad:

$permission->setException('BackEnd',array('Default', 'default'));
// $permission->setException('BackEnd:Default:default');
$permission->setException('...');

Napríklad: Super Moderátor bude napr. môcť mať prístup k daatabáze

$permission->setException('BackEnd', array('Database', NULL));

Alebo to riešiť spôsobom phpBB (Moderátori majú vlastný panel, Admini tiež, Useri tiež)…

A k tomu problému s prístupovými právami
Povedz mi takú skupinu, ktorá nevyhovovala tejto danej tabuľke…
Predstav si terč, v strede sú základné nastavenia, v druhej úrovni je správa administrátorskej skupiny, v tretej úrovni: dajme tomu, že správa ostatných skupín…

Nie je možné aby niekto, kto má právo pristupovať k správe ostatných skupín mohol pristupovať k základným nastaveniam webu atp.

Editoval Peter9 (17. 2. 2011 16:55)

před 14 lety
Aurielle
Člen | 1281
+
0
- 
$acl->allow('moderator', 'articles');	// Povolí moderátorům dělat všechny operace nad article
$acl->deny('moderator', 'articles', 'delete');	// Zakáže moderátorům operaci delete nad article
před 14 lety
Peter9
Člen | 69
+
0
-

No hej, ok, ale, ak mám BackEnd modul?

Ale aj tak, treba nad DB dlho rozmýšľať a nájsť ten správny a hlavne efektívny spôsob…

Editoval Peter9 (17. 2. 2011 17:09)

před 14 lety
srigi
Nette Blogger | 558
+
0
-

@Peter9 skus kuknut na tuto diskusiu.

před 14 lety
Peter9
Člen | 69
+
0
-

Rozpráva sa tam o Bohvieakých anotáciách (čo to je?) – môj problém je o inom kafči. Ide o toto:

https://doc.nette.org/…oli-a-zdroju

Mojím problémom sú 2 veci:

  1. Resources (Neviem, koľko ich bude, aké veľké budú, atp.)
  2. Roles, neviem koľko ich bude, ale budú dynamicky sa meniace via BackEnd…

A ku problému „prístupných“ a „neprístupných“ vecí: Môžem v DB urobiť stĺpec, kde vymenujem jeho povolenia (ak by to bolo nutné) vo formáte CSV (napr. MojSuperKamos bude admin a dostane výnimku do sekcii: 1,2,5 pričom {0,1,2,3,4,5,6,7,8} je množina možných hodnôt, zoradených podľa dôležitosti).
Á zase, ak by existoval človek, ktorý môže editovať veci 5. úrovne a potrebuje niečo zo 7. úrovne, som tu ja (ako Root). Ak by som chcel človeku povoliť prístup do 7. úrovne BackEndu, musel by som mať na to sakra dobrý dôvod. A tiež neviem prečo by niekto, kto má prístup do 5. úrovne (povedzme správa fóra), by som mu mal dať „čiastočný“ prístup do 6. úrovne – ak je adekvátna potreba, je na mieste posunúť tohto človeka o úroveň vyššie.

Nthin' is impossible.

Nehovorím, že Nette metóda je zlá, len sa mi zdá, že z pohľadu implementácie stráca na výkone (ak by to bol väčší/veľký projekt)…

Editoval Peter9 (17. 2. 2011 18:50)

před 14 lety
norbe
Backer | 405
+
0
-

Jenže u většího projektu právě potřebuješ mít možnost rozdělit pravomoci přesně tak, jako je to navržené v nette. Představ si třeba rozsáhlej eshop o který se stará několik (desítek) lidí. Jedni budou mít na starosti objednávky, další úpravu produktů, někdo třeba zase vyřizování reklamací. Při takovém členění pak nemůžeš vytvořit přístupy na základě levelů. Tyto sekce mají stejnou důležitost, ale přesto by osoby zařazené do jedné skupiny neměli mít právo dělat věci z jiné skupiny.

před 14 lety
Peter9
Člen | 69
+
0
-

Mhmm…No ale ku každej skupine ľudí uvádzať čo smie a nesmie? Ak je to tak, tak potom prečo uvádzať viewy? Ako by si to napísal? Ak ku každej skupine ľudí priradíme minimálne 1 presenter, načo uvádzať view? Admin napr. smie všetko, netreba menovať ktoré kontrolery smie. To isté u každej menšej množine ľudí, prečo mám menovať ktoré views áno a ktoré nie? Ak si majú nejakú kafrať do roboty, tak nech to robia cez svoje* presenteri a nie povoľovať im jednú alebo dve akcie pomocou permissions aby sa mohli dostať už aj tak ku obmedzenej funkčnosti…

  • – svoje alebo spoločné presenteri, myslím tým, že nie je nutné vytvárať duplicitné presenteri…
před 14 lety
norbe
Backer | 405
+
0
-

Opět vezmu příklad z eshopu. Mám člověka co má na starosti reklamace. Ten by měl určitě mít možnost zobrazit si objednávky od uživatele, který reklamuje zboží a zkontrolovat, jestli si zboží skutečně zakoupil. Neměl by ale mít možnost objednávky zpracovávat. Ale prohlížení a zpracování objednávek nejspíše bude implementované v jednom presenteru (zde se bere ona potřeba kontroly pro jednotlivé akce/pohledy).

Nic Ti ale nebrání to takto nerozlišovat a k danému presenteru povolit určité skupině lidí vše. To, jak moc budeš oprávnění zjemňovat je čistě na Tobě. Doporučuji ti (ještě jednou) si pořádně projít dokumentaci k třídě permission.

před 14 lety
paranoiq
Člen | 392
+
0
-

ad výkon: spočítané dvojice resource/action můžeš kešovat. třeba pro každou roli nebo i pro každého uživatele. celou strukturu ACL pak bude třeba načíst v podstatě jen při zásahu do práv

před 14 lety
bojovyletoun
Člen | 667
+
0
-

Jen doplním, že jednoduchý návod na kešování je na koncitohoto tohoto návodu na dyn.ACL