Planiranje i usability Planiranje, legalnost, privatnost, arhitektura, principi |
|
Alati teme | Način prikaza |
20. 03. 2006. | #1 |
Ivan Dilber
Sir Write-a-Lot
|
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?
__________________
Leadership is the art of getting people to want to do what you know must be done. |
20. 03. 2006. | #2 |
Dejan Katašić
Wrote a book
Datum učlanjenja: 10.06.2005
Lokacija: Novi Sad
Poruke: 1.017
Hvala: 129
86 "Hvala" u 43 poruka
|
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. |
20. 03. 2006. | #3 |
Igor Marinović
Expert
|
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. |
20. 03. 2006. | #4 | |
VD IT Direktora
Invented the damn thing
Datum učlanjenja: 08.06.2005
Lokacija: Beograd
Poruke: 2.118
Hvala: 503
1.307 "Hvala" u 282 poruka
|
Citat:
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. Poslednja izmena od jablan : 20. 03. 2006. u 15:19. |
|
20. 03. 2006. | #5 | |
Ivan Dilber
Sir Write-a-Lot
|
Citat:
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...
__________________
Leadership is the art of getting people to want to do what you know must be done. |
|
20. 03. 2006. | #6 | |
VD IT Direktora
Invented the damn thing
Datum učlanjenja: 08.06.2005
Lokacija: Beograd
Poruke: 2.118
Hvala: 503
1.307 "Hvala" u 282 poruka
|
Citat:
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. |
|
20. 03. 2006. | #7 | |
old school
Professional
Datum učlanjenja: 15.06.2005
Lokacija: Novi Beograd
Poruke: 448
Hvala: 21
70 "Hvala" u 46 poruka
|
Citat:
- 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.
__________________
http://www.vesic.org | Blog: http://www.vesic.org/blog/ | Fina kolekcija programa: http://www.vesic.org/programi/ |
|
20. 03. 2006. | #8 |
Igor Marinović
Expert
|
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.
|
20. 03. 2006. | #9 | |
old school
Professional
Datum učlanjenja: 15.06.2005
Lokacija: Novi Beograd
Poruke: 448
Hvala: 21
70 "Hvala" u 46 poruka
|
Citat:
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.
__________________
http://www.vesic.org | Blog: http://www.vesic.org/blog/ | Fina kolekcija programa: http://www.vesic.org/programi/ |
|
20. 03. 2006. | #10 | |
Direktor Kombinata
Invented the damn thing
Datum učlanjenja: 07.06.2005
Poruke: 2.669
Hvala: 44
119 "Hvala" u 64 poruka
|
Citat:
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:
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.
__________________
activeCollab - Project Management and Collaboration Tool iz domaće kuhinje | area51.rs - Blog Poslednja izmena od Ilija Studen : 20. 03. 2006. u 20:22. |
|
|
|
Slične teme | ||||
Tema | Početna poruka teme | Forum | Odgovori | Poslednja poruka |
računanje sistema na tiketu pomoću ASP.NET | sondlic | Programiranje | 5 | 14. 04. 2009. 15:09 |
Softver za pravljenje shema informacionog sistema | alex | Opušteno | 3 | 07. 02. 2008. 03:45 |
Zaštita podataka od pada sistema | Petar Marić | Opušteno | 7 | 23. 11. 2006. 13:59 |