Prava korisnika u administraciji

[zorro128]

Zanima me kako najelegantnije riješiti probleme prava pristupa korisnika koji se mogu ulogirati u administraciju.

Naime prilikom logiranja u administraciju preko sessiona prenosim id korisnika i na osnovi toga bi sada trebao odrediti koja sva prava korisnik ima. Znači ože li brisati ili dodavati članke. Kako svoje tako i članke drugih korisnika.

Jel možda najbolje napraviti zasebnu tablicu koja bi sadržavala listu korisnika koji imaju prava pristupa administraciji plus prava koja imaju nakon logiranja.

Zanima me vaša praksa u ovome slučaju budući da se nisam prije susretao s ovim.

Malo sam gledao kako je u Joomli to riješeno, ali mi se ne sviđa što je to riješeno preko grupa. Volio bi malo specifičniji pristup.

[tsereg]

Ne znam da li sam razumio pitanje.

Jedan načelni prijedlog, ali neću tvrditi da ne postoji nešto elegantnije:

Podijeli funkcionalnost programa u specifične operacije/funkcije. U kodu, na mjestima gdje su te operacije implementirane, naprosto baci iznimku (exception) ukoliko korisnik nema dodijeljeno odgovarajuće pravo.

Što si bolju funkcionalnu dekompoziciju napravio tijekom analize to bi ti ugradnja tih provjera bila jednostavnija.

Što finiju granulaciju operacija napraviš, imat ćeš finiju kontrolu prava, ali će sistem dodijeljivanja prava biti kompliciraniji, a ugradnja provjera kompleksnija.

Primjerice, za ovaj forum bi operacije mogle biti:
- edit any post
- delete any post
- delete any thread
- close any thread
- move any thread

Čini mi se da bi ključno bilo upravo inteligentno odabrati operacije koje se dozvoljavaju ili ne dozvoljavaju.

Pri tome posebno mislim na razinu na kojoj vršiš dodjelu prava. Mogao bi, recimo, to raditi na razini tablica (dopusti ovom korisniku da upisuje ili briše zapise u ovoj ili onoj tablici), ali bi onda možda otkrio da nisi sposoban korisniku dodijeliti prava koja želiš, jer ćeš uvijek doći na to da svim korisnicima moraš dodijeliti sva prava nad svim tablicama. Znači, morao bi se konceptualno popeti razinu više.

Također bi mogao otkriti da moraš napraviti i klasifikaciju objekata foruma na neki način. Primjerice, postovi na forumu moraju biti podijeljeni u dva razreda: "any post" i "own post", kako bi imao pravo "delete own posts" i "delete any posts".

[zorro128]

Evo ovako. Cijeli sajt je organiziran tako da svaka funkcionalnost predstavlja objekt. Znači sadržaj je jedan objekt nad kojim bi morao odrediti koja su prava pristupa tom objektu i akcije nad nji. Isto vrijedi i za korisnike i kategorije. Poslije će naravno biti još objekata, ali za ovo što sam dosada napravio trebao bih riješiti prava pristupa.

Uglavnom svaka funkcionaslnost je predstavljena objektom.

[djomla]

Mozda bi ti bilo bolje i lakse da korisnike vezes za odredjene grupe, primjer administrators, demo, users, whatever :)

A onda tim grupama dajes prava (read, write .. etc.) na odredjene module koje imas.

[zorro128]

To sam na početku mislio. Tako je u Joomli riješeno, ali želim malo specifičniji pristup.

[djomla]

Pa ovo je po meni elegentno. Ici raditi za svakog usera pojedinacno prava i dozvole je po meni ne prakticno.

[zorro128]

Možda jest nepraktično, ali nekad je potrebno. Ovisno potrebama samog sustava. A ovaj sustav to zahtjeva.

[tsereg]

Pojam "funkcionalnost" se ne odnosi na stvari, već na akcije. Sadržaj nije funkcionalnost. Uređivanje sadržaja jest funkcionalnost. Ukoliko, primjerice, postoji funkcija koja dohvaća traženi sadržaj iz baze i potom ispisuje TEXTAREA element, onda bi na početku te funkcije naprosto provjerio da li korisnik ima pravo korisititi tu funkciju i bacio iznimku ako nema. Slično i za funkciju spremanja sadržaja po POST metodi, itd.

Dakle, koliko su ti *procesi* dobro funkcionalno dekomponirani u funkcije, toliko bi mogao lijepše definirati osnovna prava i ugraditi njihovu provjeru.

---------

Vidi kako je to riješeno u CMS-u TYPO 3:
http://typo3.org/documentation/document-library/core-documentation/doc_core_inside/4.1.0/view/3/4/

[zorro128]

Pa koliko ja vidim jesu. Svaka akcija je predstavljena funkcijom. Pa tu ne bi trebalo biti problema.

[franzi]

Ja kad sam to radio, riješio sam putem grupa i članstva u grupama.

Dakle, definiraš operacije koje useri mogu raditi na stranici, kao što je tsereg naveo. Kod mene su to bili:
- dodavanje komentara
- brisanje komentara
- dodavanje usera
- brisanje usera
- editiranje usera
- dodavanje anketa
- brisanje anketa
- itd.

Sada, kreiraš jednu tabelu grupe: id | dodkom | briskom | doduser | brisuser | ...

Kvaka je u tome da sam ja napravio da se userima dodjeljuju grupe, a ne obratno. Dakle, jedan user je mogao imati više pridruženih grupa, što teoretski znači da se je mogla kreirati za svaku akciju jedna grupa, što na kraju ispada da je grupa = dozvola akcije.

To sam učinio tako da sam između tabele useri i tabele grupe stavio jednu n:m relacijsku tabelu useri_grupe : id_user | id_grupa.

Zatim sam, pri loginu usera, određenim sql upitom i procedurom dobio sve permisije za tog korisnika. Potom sam ih spremio u sam session tako da ne moram svaki put vršiti sql upit, a potom sam vrlo lako prilikom navedenih akcija provjeravao: if ($_SESSION['user']['dozvole']['briskom'] == 1) {možeš obrisati usera} else {marš odavde}.

Nedostatak ovakvog sistem vidim jedino u tome što moraš prije definirati sve akcije i moraš ih sam mijenjati kao polja u tabeli.

[glavince]

U jednom mom projektu koji sadrzi kategorije i podkategorije recimo:
1. vesti
- unesi
- izmeni
- brisi
- naslovna
2. komentari
- izmeni
- brisi
3. ankete
- unesi
- izmeni
- brisi
4.
i t.d.

Posto nacin rada zahteva tako, za svakog usera t.e. admina dodejlavam posebno prava. Neko sme da pise vjesti, neko sme samo da vrsi izmene ili da brise. I to da mogu da odredim da vrsi izmenu ili da brise samo njegove vjesti ili od svih admina.
Isto i sa ostalim kategorijama i podkategorijama.

U attachment sam stavio print screen kako izgleda admin panel za dodeljivanje prava za jednog usera.

[sonam]

Ja moram priznati da bih to rijesio tablicom. U stupce bih metnuo dozvole pristupa, a u redove usere. Npr.:

_______|_________EDIT_________|__________NEW______ ____|___________ DELETE__________|
User 1 | section1|section2 | section1 | section1 |
User 2 | section3|section4 | section3|section4 | section3|section4 |
User 3 | section2|section4 | section4 | section4 |


Nakon sto bi se user logirao s explode bih definirao $_SESSION['edit'], etc., a zatim bi s if array search === True isprintao ili ne isprintao odgovarajuci button.
To bi u slucaju usera 1 znacilo da ce u sekciji 1 imati buttone EDIT, NEW i DELETE, a u sekciji 2 samo EDIT.

Sonam

[franzi]

Nije sasvim elegantno raditi explode određenih polja u tabeli jer se to može izbjeći boljim dizajnom baze.

[tsereg]

Naravno. Zapis može biti jednostavno oblika (user_id, action, section), pri čemu je cijela trojka UNIQUE. "User_id" je oznaka korisnika, "action" je jedna od gornjih akcija "new", "edit", "delete", a "section" je sekcija kako je gore navedeno. Na ovaj način se mogu proširivati akcije, mogu se kreirati efektivni upiti i sl.

[sonam]

Nije sasvim elegantno raditi explode određenih polja u tabeli jer se to može izbjeći boljim dizajnom baze.

Pa naravno, ja se bas ne bavim MySQL bazama pa ne treba moj primjer uzeti doslovno, a svatko ce problem rijesiti na svoj nacin. BTW svidja mi se Tseregova ideja.

Sonam

[zorro128]

Tsreg je predložio finu ideju. To sam i napravio, ali sam umjesto user_id koristio user_ac koji označava prava pristupa korisnika. Admin ima vrijednost 100, registrirani korisnik 10, a publisher 90.

Još jedno pitanje, nevezano za prava pristupa. Koji template sistem je najbolji? PatTemplate,smarty,... ili već neki drugi.

[djomla]

smarty definitivno

[zorro128]

Jel imaš kakve tutoriale za smarty ili čak bolje da mi pošalješ neke primjere predložaka da vidim kako si radio. Bilo bi mi od velike pomoći.

[djomla]

mogu slozit tutorial brzi pa staviti ovdje na webmajstore ...

[Sky]

Smarty ima predobru dokumentaciju, gotovo svaka funkcija, modifier, insertion ili nešto drugo ima napisan i primjer kako koristiti te što se dobije kao rezultat.

http://smarty.php.net/manual/en/

[zorro128]

Pregledao sam dokumentaciju. ODlična je. Ali ipak jedan uživo primjer ne bi škodio. Čisto da vidim strukturu template-a.

[dezlux]

Poštovanje!

Žao mi je što ovaj post nisam pročitao prije jer tada nebih pisao svoj sustav privilegija....

Moja aplikacija se sastoji od korisnika, grupa i modula.
- Korisnik pripada nekoj grupi.
- Svakoj grupi dodjeljuju se instalirani moduli.
- Svaki modul ima proizvoljan broj operacija (tipa edit, delete, insert) te pripada nekoj domeni tipa admin, member i public ( koji stupanj sigurnosti primjeniti, Publi modul je otključan za sve, admin module pokreće samo admin).

Tako pri instalaciji modula operacije se upisuju u tablicu operation te se stvara dodatna tablica imena modula (za mene je objekt neki text ili post koji modul stvara u mysql tablici, svaki objekt ima svog vlasnika a on pripada nekoj grupi):

____________|_edit_|_delete_|_insert_|_view_|
id_usergroup |_a___|__o____|__true_|__1,2__|

a - znaći da korisnik grupe, može vršiti operaciju edit prema svim vlasnicima objekta (all)

o - znaći own ili samo svoje

true - opčenito operacija je dozvoljena ili false suprotno

1,2 - znaći da korisnik grupe može vršiti view operaciju samo nad objektom (neki post ) ćiji su kreatori korisnici grupe 1 i 2

Neznam dali sam bio jasan ali ovaj sustav meni je donesao jedan stupanj sigurnosti.

[djomla]

Pozz ... ok rjesenje ovo sa grupama kako si postavio. Dakle logika meni makar je odokativno ok mada ovo sa ovom tablicom mislim da i nije naj sretnije rjesenje. Stavljati pogotovo u ovakav tip tablice vrijednosti "1,2" i da to cini neku "vezu" nije ga bas zgodno. Dobro mozda sam fulao, al bi volio da stavis tablice koje imas ... daj njihov description ovdje pa da komentiramo svi skupa.

[dezlux]

Stavljati pogotovo u ovakav tip tablice vrijednosti "1,2" i da to cini neku "vezu" nije ga bas zgodno.

Zgodno je razdvajati ključeve sa zarezom jer onda mogu koristiti sql upit tipa

.. WHERE id_usergroup IN (1,2)

[djomla]

Ako mozes dati tablice ... valjda nije sigurnosni rizik :)

[dezlux]

Ako mozes dati tablice ... valjda nije sigurnosni rizik :)

Slika je tisuću riječi....


Znaći svaki modul ima *.ini datoteku sa popisom operacija koje podržava. Instalacijom modula parsiram sql query koji stvara tablicu te operacije unosim u tablicu module_op. U tablici module_op imam popis svih operacija,
label polje mi služi kao prijevod operacije ( _insert je u biti gumb Unesi korisnika )
jump polje je ako je operacija uspješno izvršena skoći na operaciju
button polje označava da je operacija gumb

i tako dalje

Nakon toga otvaraš grupu i dodaješ joj instalirani modul ( + - ). Nakon toga otvaraš postavke za dodani modul i vidiš operacije koje taj modul podržava. Nude ti se opcije all,own,true,false i id_usergroup koji se odvajaju zarezima.

Jezgra sustava mi koristi razne klase i funkcije koje provjeravaju tko je vlasnik objekta koji se obrađuje (autor teksta je vlasnik objekta) tako da se privilegije primjenjeuju na naćin ...

Novinar je grupa 1
novinar unosi tekstove
novinar uređuje samo svoje tekstove
novinar briše samo svoje tekstove

Urednik je grupa 2
urednik ne unosi tekstove
urednik uređuje tekstove grupe 1
urednik briše tekstove grupe 1,2

Pozdrav!

[mamica]

Molim te pojasni ove dvije situacije:
- urednik (2) ne unosi tekstove
- urednik briše tekstove grupe 2

Tko onda unosi tekstove grupe 2?

[zorro128]

Ja sam na kraju definirao tablicu:

permission

userid - id korisnika
com - komponenta (com_users,com_content,com_categories,...)
task - (list,update,delete,...)
rights (0 == nema pravo, 1== ima pravo)

U tablicu se za svaku akciju upisuje novi redak.

I nakon toga u index2.php fajlu odmah na početku provjeravam ima li korisnik pravo na određenu akciju. Ako nema vraćam ga početak, ako ima akcija se izvršava.

E sada mi je problem kako dopustiti korisniku da recimo uređuje samo svoje postove ili recimo da može samo urediti svoj profil.

[tsereg]

1. Što će ti rights? Ako ima zapisa ima pravo, ako nema, nema pravo (ili obratno). Na taj način nemaš nedefiniranu situaciju kakvu sada imaš i ujedno je svaka novododana komponenta automatski "zaključana".

2. Uoči zadnje poglavlje u postu br. 2 - upravo na ovaj problem skrećem pažnju. Klasificiraj komponente ili klasificiraj prava. Ako klasificiraš komponente, onda dodaš atribut "class", pa će se svaka komponenta opisati s onoliko zapisa koliko razreda ima. Primjerice, imat ćeš zapis s (com := "com_content", class := "all"), pa ćeš imati zapis s (com := "com_content", class := "own") ili nešto slično tome. Prednost je što različite komponente mogu imati različite kategorije. Drugi način je da ne dodaješ atribut "class", već da redefiniraš ulogu atributa "rights", tako da radi na sličan način kao što to funkcioniraju atributi datotečno sustava - nešto slično kao naredba chmod, samo što kod tebe svaki bit znači drugu kategoriju, a svi postavljeni bitovi označavaju "all". I tada, ako zapisa nema onda su sva prava povučena.

[dezlux]

Molim te pojasni ove dvije situacije:
- urednik (2) ne unosi tekstove
- urednik briše tekstove grupe 2

Tko onda unosi tekstove grupe 2?

Moja greška ali to je rupa u programu. sve se može definirati.

[tsereg]

Mali update:

Uobičajeni način dodijeljivanja privilegija korisnicima je kroz tehniku poznatu kao ACL - Access Control List. Na ACL-u se temelje prava i u operacijskim sustavima. Ovdje je opis na Wikipediji:
http://en.wikipedia.org/wiki/Access_control_list

Očiglendno je da implementacija ACL-a nije trivijalna, ali spominjem tu tehniku jer mi se čini da postoji biblioteka PHP koda koja to implementira:

http://phpgacl.sourceforge.net/

Nisam, međutim, na čistu koliko je to aktualna biblioteka i koliko se još uvijek održava.