 |
|
| ivanhoe |
20. 03. 2006. 13:10 |
projektovanje sistema privilegija
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 |
20. 03. 2006. 13:30 |
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 |
20. 03. 2006. 14:02 |
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 |
20. 03. 2006. 14:13 |
Citat:
Originalno napisao ivanhoe
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 |
20. 03. 2006. 16:06 |
Citat:
Originalno napisao jablan
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 |
20. 03. 2006. 16:18 |
Citat:
Originalno napisao ivanhoe
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 |
20. 03. 2006. 18:51 |
Citat:
Originalno napisao ivanhoe
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 |
20. 03. 2006. 19:03 |
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 |
20. 03. 2006. 19:07 |
Citat:
Originalno napisao zigor
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 |
20. 03. 2006. 19:19 |
Citat:
Originalno napisao zigor
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 kôd:
<?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. |
| Vreme je GMT +2. Trenutno vreme je 23:27. |
|
Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.
Mišljenja, saveti, izjave, ponude ili druge informacije ili sadržaji nastali na Sajtu su vlasništvo onoga ko ih je kreirao, a ne DevProTalk.com, tako da ne morate da se oslanjate na njih.
Autori poruka su jedini odgovorni za ovakve sadržaje. DevProTalk.com ne garantuje tačnost, kompletnost ili upotrebnu vrednost informacija, stavova, saveta ili datih izjava. Ne postoje uslovi pod kojima bi mi bili odgovorni za štetu ili gubitak koji je posledica bilo čijeg oslanjanja na nepouzdane informacije, ili bilo kakve informacije nastale kroz komunikaciju između registrovanih članova.Web sajt može sadržavati linkove na druge web sajtove na Internetu ili neke druge sadržaje. Ne kontrolišemo niti podržavamo te druge web sajtove, niti smo pregledali bilo kakve sadržaje na takvim sajtovima. Mi nećemo biti odgovorni za legalnost, tačnost ili prikladnost bilo kog sadržaja, oglasa, proizvoda, usluga ili informacije lociranim na ili distribuiranih kroz druge web sajtove, niti za bilo kakvu štetu nastalu kao posledica takvih informacija. DevProTalk.com drži i čuva druga prava vlasništva na web sajtu. Web sajt sadrže materijale zaštićene copyright-om, zaštitne znakove i druge informacije o pravu vlasništva ili softver. Članovi mogu poslatu informacije zaštićene pravima vlasništva njihovih nosilaca i ona ostaju zaštićena bez obzira da li su oni koji prenose te informacije to naveli ili ne. Osim informacija koje su u javnom vlasništvu ili za koje dobijete dozvolu, nemate pravo da kopirate, modifikujete ili na bilo koji način menjate, objavljujete, prenosite, distribuirate, izvršavate, prikazujete ili prodajte bilo koju informaciju zaštićenu pravima vlasništva. Slanjem informacija ili sadržaja na bilo koji deo DevProTalk.com, Vi automatski dozvoljavate i predstavljate garanciju da imate pravo da dozvolite DevProTalk.com ili članovima DevProTalk.com bespovratnu, kontinualnu, neograničenu, globalnu dozvolu da koriste, kopiraju, izvršavaju, prikazuju i distribuiraju takve informacije i sadržaje i da iz takvih sadžaja koriste bilo koji deo u bilo koje svrhe, kao i pravo i dozvolu da koriste gore navedene sadržaje. Svi zaštitni znakovi (trademarks), logotipi, oznake usluga, firme ili imena proizvoda koji se pominju na ovom web sajtu su vlasništvo kojim raspolažu njihovi vlasnici.