projektovanje sistema privilegija

[ivanhoe]

zanima me kakva su vasa iskustva sa kontrolom ko, sta i gde sme da radi na sajtu, i kako to sto flexibilnije i efikasnije uraditi (flexibilnost i efikasnost su ovde suprotstavljeni zahtevi).

Da li koristiti nivoe (svaki user ima neki nivo ovlascenja, i svaka akcija ima svoj minimalni nivo, i onda ako user_nivo >= min_nivo operacija je dozvoljena, pri cemu nivoi mogu da izrazeni numericki ili preko uloga(roles) kojima je dodeljen nivo), ili mislite da je bolje praviti grupe sa polisama gde za svaku pojedinu akciju postoji flag da li je dozvoljena datoj grupi ?

Drugo resenje omogucava precizniju kontrolu, ali postoji problem da je potrebno definisati sve mogucu akcije unapred, sto je smor za web dev, jer znaci provera se sprovodi tako sto se navede ime akcije i onda se proveri da li user to sme da radi. To znaci kad god pises novu skriptu koja radi nesto novo treba da u bazi definises ko sme to da radi, a to je neprakticno. Moguca modifikacija je da se provera u kodu vrsi tako sto se gleda da li user pripada odredjenoj grupi za koju se cini da ima potrebne privilegije, ali onda je problem sto promene u pravima grupe nece uticati na taj kod, sto je losa ideja..

Prvo resenje nema taj problem jer u samoj skripti kad se radi provera treba samo navesti potrebni min. nivo, ali postoji problem oko gradacije privilegija,jer svaki visi nivo ima automatski sve privilegije nizeg plus nesto, sto nije uvek bas realna situacija. Cisto kao ilustracija mozda npr. zelim da neko moze da edituje odredjeni tudji dokument, ali ne zelim da moze da mu chita mail samim tim..

Dakle, kako vi to resavate?

[noviKorisnik]

Teško da možeš da dobiješ recept. Predstavi sistem u kom treba da egzistiraju ti korisnici, uoči razlike među njima, grupiši ih, itd. ...

Pogledaj recimo blog - imaš jednog ili više urednika, ostalo su samo posetioci ili najviše registrovani korisnici (ako ograničavaš pravo na komentare).

Na forumima je već mnogo veća muka - svaki forum ima svoje urednike, koji na ostalim forumima mogu da budu samo obični korisnici.

U poslednje vreme mi je zanimljiv koncept social networkinga - korisnici mogu sami da kreiraju grupe i da definišu neki skup pravila za grupu, da biraju kojim grupama žele da se priključe a kojim ne.

Primer - ako gledam nečiju sliku na flickru ne mogu da dodajem tagove ukoliko se ta slika ne nalazi i u galeriji neke od mojih grupa.

[marinowski]

Sve zavisi od toga sta ti tacno treba.

Mi obicno radimo metodu 2: lista (moze i drvolika struktura) objekata, lista akcija u drugoj tabeli, i onda dozvole sta ko sme u trecoj tabeli. Drvolika hijerarhijska struktura je dobra, jer ne moras da zadajes za svaki objekat pojedinacno, nego mozes da kazes: korisniku je dozvoljena akcija rekurzivno za ovaj objekat i svu njegovu decu.

[jablan]

To znaci kad god pises novu skriptu koja radi nesto novo treba da u bazi definises ko sme to da radi, a to je neprakticno.
A zašto misliš da je ovo nepraktično? Kad već pišeš novu akciju (ajde recimo da podrazumevamo da je nova skripta = nova akcija), što bi ti bio problem da dodaš par redova u odgovarajuće tabele? BTW, mi recimo imamo alat (desktop aplikaciju) za developere kojim se odrađuju ovakve stvari.

Mi u našem projektu imamo prilično komplikovan sistem privilegija. U osnovi se svodi na model User-Group-Role-Activity.

Naravno, za jednostavnije potrebe je i sistem numeričkih nivoa sasvim OK.

[ivanhoe]

A zašto misliš da je ovo nepraktično? Kad već pišeš novu akciju (ajde recimo da podrazumevamo da je nova skripta = nova akcija), što bi ti bio problem da dodaš par redova u odgovarajuće tabele? BTW, mi recimo imamo alat (desktop aplikaciju) za developere kojim se odrađuju ovakve stvari.

uzmi da imas neki community sajt sa par hiljada usera, sa razradjenim sistemom privilegija, grupa, imas forum, blog, imterni email sistem, mogucnost grupnog editovanja dokumenata i tako to... i onda dodas neku novu skriptu sa 5-6 novih akcija...

nije bas banalna stvar azurirati ko tu sta sme da radi, bez obzira na interfejs, ipak treba proci kroz sve grupe i razmisliti o posledicama, a narocito je nezgodno kod sistema koji nasledjuju neke privilegije na osnovu hijerarhije (ako si u nadredjenoj grupi automatski imas privilegije svih sub-grupa), jer tu potencijalno postoje side-effecti koji nisu bas ocigledni...

[jablan]

uzmi da imas neki community sajt sa par hiljada usera, sa razradjenim sistemom privilegija, grupa, imas forum, blog, imterni email sistem, mogucnost grupnog editovanja dokumenata i tako to... i onda dodas neku novu skriptu sa 5-6 novih akcija...
Pa ne kažem ja da ti ne možeš toliko da zakomplikuješ sistem da dodavanje prava pristupa za novu funkcionalnost postane pakao... Ja ti samo velim, mi imamo jako složen proizvod (komercijalni CMS) i dodavanje nove akcije nije neki problem.

A što se tiče privilegije na osnovu hijerarhija, obično se ne prave hijerarhije rola, već grupa, a prava se ne vezuju za grupe, već za role, tako da hijerarhija nije dodatni problem.

[DejanVesic]

Prvo resenje nema taj problem jer u samoj skripti kad se radi provera treba samo navesti potrebni min. nivo, ali postoji problem oko gradacije privilegija,jer svaki visi nivo ima automatski sve privilegije nizeg plus nesto, sto nije uvek bas realna situacija. Cisto kao ilustracija mozda npr. zelim da neko moze da edituje odredjeni tudji dokument, ali ne zelim da moze da mu chita mail samim tim..

Dakle, kako vi to resavate?

Jedno od (meni) vrlo udobnih rešenja je:

- napravim akcije (privilegije)
- napravim role i dodelim rolama akcije

Međutim, role su ZABRANA - tj. ako korisnik pripada roli, onda on NE SME da koristi date akcije. Tj. recimo SUPERUSER rola nema ni jednu akciju (prazna je).

Ostaje još tabela USERROLE (user, rola) - ovde za svakog korisnika pobrojim kojim rolama pripada.

Sada je procedura za proveru da li je akcija korisniku dozvoljena vrlo prosta:

(0) prosledim (user,privilegija) proceduri
(1) procedura krene po USERROLE tabeli za datog korisnika
(2) dovuci sve privilegije za rolu iz tekućeg sloga iz (1)
(3) ako je privilegija jednaka prosleđenoj, odmah izađem i javim NE_MOZE
(4) ako sam prosao sve slogove iz USERROLE i sve privilegije i ni jedna se ne podudara, vratim MOZE

(*) Naravno, (1) je u stvari JOIN između USERROLE i ROLEPRIV tabele + distinct - ovo je samo da opis bude jasniji.

Ovako ne brinem za dodavanje novih akcija - kada dodam novu akciju, dozvoljena je svima. Ako moram nekom da uskratim, samo je dodam odgovarajućoj roli i gotovo.

Ovo sam koristio puno puta i pokazalo se kao fino fleksibilno.

[marinowski]

Meni je blizi jablanov pristup ... Meni se cini prirodnije da dodajes novu akciju i da je dozvolis malom broju korisnika, nego da je zabranjujes svima. Ako se dodaje vrlo senzitivna akcija (kao sto je npr. slanje SMS-a grupi od 300.000 korisnika), tim pre volim da je to po defaultu zabranjeno.

[DejanVesic]

Meni je blizi jablanov pristup ... Meni se cini prirodnije da dodajes novu akciju i da je dozvolis malom broju korisnika, nego da je zabranjujes svima. Ako se dodaje vrlo senzitivna akcija (kao sto je npr. slanje SMS-a grupi od 300.000 korisnika), tim pre volim da je to po defaultu zabranjeno.

Pa, sve zavisi od vrste sistema koji praviš - ako je sistem koji praviš jako restriktivan i sa puno no-no varijanti, onda gore opisan način nije pogodan.

Ako pak sa druge strane postoji mali broj akcija koje se zabranjuju, a ostale su po defaultu dozvoljene (više sam radio ovakve sisteme) onakav način je sasvim, sasvim fin.

[Ilija Studen]

Sve zavisi od toga sta ti tacno treba.

Mi obicno radimo metodu 2: lista (moze i drvolika struktura) objekata, lista akcija u drugoj tabeli, i onda dozvole sta ko sme u trecoj tabeli. Drvolika hijerarhijska struktura je dobra, jer ne moras da zadajes za svaki objekat pojedinacno, nego mozes da kazes: korisniku je dozvoljena akcija rekurzivno za ovaj objekat i svu njegovu decu.

Sistem koji sam koristio u jednoj aplikaciji razdvaja dozvole i grupe. Dozvole su hijerarhijski organizovane (npr, da bi čovek dodao stranicu na sajt treba da ima pristup administraciji, pristup pages modulu i pravo da dodaje stranice; ako je bilo šta od toga false ništa od dodavanja). Pri definisanju dozvole omogućeno je setovanje default vrednosti tako da opšti slučaj čak i ne zahteva konkretnu vezu između grupe i dozvole sa vrednošću već može da se koristi podrazumevana vrednost.

Dozvole se keširaju u jedan asocijativni niz tako da to odstranjuje većinu probleme sa performansama. ($perms['group_id']['permission_name'] = value). Evo ga izvod iz cachea za tu aplikaciju:

<?php
return array (
1 =>
array (
'admin_index' => true,
'auth_add_group' => true,
'auth_add_permission' => true,
'auth_add_user' => true,
'auth_create_cache' => true,
'auth_delete_group' => true,
// ...
));

?>

Dodavanje akcija je prilično jednostavno. Pošto je sistem MVC projuri kroz sve dostupne kontrolere, skonta public metode (akcije) i na osnovu toga ti ponudi formu pomoću koje možeš da dodaš masu dozvola u jednom prelazu. Kasnije ih samo ispreturaš u hijerarhiji ako imaš potrebu za tim. Možeš da se iživljavaš i napraviš i da sinhrnoziju dozovle u bazi sa definisanim akcijama u kontrolerima (ako recimo izbaciš određenu akciju) itd, ali to su već finese u koje vredi uložiti vreme ako ćeš to rešenje često koristiti.

Rešenje samo po sebi se možda čini komplikovanim i definitivno nije za svaku skriptu, ali ako imaš dobru osnovu i potrebu za ovim relativno lako se implementira.

[ivanhoe]

Pa ne kažem ja da ti ne možeš toliko da zakomplikuješ sistem da dodavanje prava pristupa za novu funkcionalnost postane pakao... Ja ti samo velim, mi imamo jako složen proizvod (komercijalni CMS) i dodavanje nove akcije nije neki problem.

pazi, no hard feelings, ali od toga sto vi imate sistem u kome to radi super, bez da mi kazes vise detalja o tome, meni zaista nista ne koristi.. mogu samo da budem impresioniran....:)

sve moze da se napravi, naravno, mene zanimaju neki konkretni koncepti koji su se pokazali ok u praksi, da bih imao odakle da krenem sa radom..

U svakom slucaju hvala svima na savetima, iskopao sam i na netu neke tekstvoe, pa mislim da imam dovoljno informacija za pocetak...:)

[jablan]

pazi, no hard feelings, ali od toga sto vi imate sistem u kome to radi super, bez da mi kazes vise detalja o tome, meni zaista nista ne koristi.. mogu samo da budem impresioniran....:)
Sorry, nisam znao da se stiče utisak da neću da iznesem više detalja...

U principu, rešenje je slično Vesićevom (samo što su privilegije pozitivne, a ne negativne - ako rola ima akciju, ima pravo na nju). Osim što mi imamo i grupe - više korisnika može da se spakuje u grupu, a role se mogu dodavati i korisnicima i grupama.

Prava pristupa se ne definišu na nivou stranice ili kontrole (ne znam tačno naziv za veb kontrole u PHP terminologiji), već na nivou akcije (npr. kreiranje novog dokumenta, checkin, checkout, brisanje, pomeranje itd) i to za pojedinačni tip dokumenta. Takođe se prava pristupa definišu i na konkretnim dokumentima, ali ne na nivou akcija, već na nivou pristupa - da li korisnik ima ili nema pristup konkretnom dokumentu.

Workflow sistem je posebna priča zbog svoje složenosti. Prava se definišu na nivou akcije, tj. da li određena rola ima pravo da prevede dokument iz stanja A u stanje B (na primer publishovanje dokumenta itd).

Što se keširanja tiče, nemamo potrebe to da držimo u memoriji jer je sva logika filtriranja po pravu pristupa u samoj bazi, odnosno u stored procedurama. Imamo keširanje već izvučenih (i filtriranih po pravu pristupa) podataka iz baze, deo ključa je i korisnikov ID, ali to je opet posebna priča...

Ako te interesuje još nešto, pitaj. Rado bih ti dumpovao ovde strukturu baze, ali bojim se da se to kosi sa ugovorom koji sam potpisao. ;)

[zextra]

http://phpgacl.sourceforge.net/

Vrlo fleksibilan sistem kontrole dozvola. Moguce su i allow i deny dozvole, i to izmedju usera (i celih grupa) sa jedne strane, akcija (ili objekata, po terminologiji ove klase) koje mogu da izvrsavaju sa druge strane, i objekata na kojima se doticne akcije mogu izvrsavati sa trece strane. Terminologija koja se koristi je malo uvrnuta, kao i administrativni interfejs, ali postoje API funkcije koje omogucavaju sve vrste promena na userima, dozvolama, objektima, etc.. na vrlo lak nacin. Najbitnija stvar je funkcija za proveru acl_check() koja prihvata 4 parametra i ima boolean output. Po recima autora, sistem je vrlo skalabilan - navodno postoji sistem sa preko 60000 korisnika, 200 grupa i 300 razlicitih akcija (objekata).

Napisao sam par klasa koje mi omogucavaju zamalo kompletnu funkcionalnost doticne klase, sa nesto poboljsanja. Usput sam iz celog sistema izdvojio klasu koja sluzi samo za upravljanje drvolikim strukturama (dodaj nod, obrisi nod, pomeri nod, stuff like that...), koja je takodje vrlo fleksibilna, pa ako nekom treba nesto slicno, nek se javi :)

[noviKorisnik]

Оvo je recimo sve od privilegija što može da se setuje na SharePoint timskim sajtovima:

List Rights

Manage List Permissions - Grant, deny, or change user permissions to a list.
Manage Lists - Approve content in lists, add or remove columns in a list, and add or remove public views of a list.
Cancel Check-Out - Check in a document without saving the current changes.
Add Items - Add items to lists, add documents to document libraries, add Web discussion comments.
Edit Items - Edit items in lists, edit documents in document libraries, edit Web discussion comments in documents, and customize Web Part Pages in document libraries.
Delete Items - Delete items from a list, documents from a document library, and Web discussion comments in documents.
View Items - View items in lists, documents in document libraries, view Web discussion comments, and set up e-mail alerts for lists.

Site Rights

Manage Site Groups - Create, change, and delete site groups, including adding users to the site groups and specifying which rights are assigned to a site group.
View Usage Data - View reports on Web site usage.
Create Subsites - Create subsites such as team sites, Meeting Workspace sites, and Document Workspace sites.
Manage Web Site - Grants the ability to perform all administration tasks for the Web site as well as manage content and permissions.
Add and Customize Pages - Add, change, or delete HTML pages or Web Part Pages, and edit the Web site using a Windows SharePoint Services-compatible editor.
Apply Themes and Borders - Apply a theme or borders to the entire Web site.
Apply Style Sheets - Apply a style sheet (.CSS file) to the Web site.
Browse Directories - Browse directories in a Web site.
View Pages - View pages in a Web site.

Personal Rights

Manage Personal Views - Create, change, and delete personal views of lists.
Add/Remove Private Web Parts - Add or remove private Web Parts on a Web Part Page.
Update Personal Web Parts - Update Web Parts to display personalized information.
Create Cross-Site Groups - Create a group of users that can be granted access to any site within the site collection.

[ivanhoe]

Osim što mi imamo i grupe - više korisnika može da se spakuje u grupu, a role se mogu dodavati i korisnicima i grupama.


hvala na opisu, i naravno da se podrazumeva da ne mozes da objavljujes podatke o sistemu... ali kao sto rekoh mislim da sam iz ove price stekao neku perspektivu o mogucim arhitekturama ovakvog sistema, nazvrljao sam gomilu papira sa dijagramima, kockicama i strelicama, sad jos samo da skrpim slobodnog vremena da napisem neki kod za to :)