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 | |
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 19:22. |
|
20. 03. 2006. | #5 | |
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 14:19. |
|
20. 03. 2006. | #6 | |
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. | #7 | |
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. |
|
21. 03. 2006. | #8 | |
Ivan Dilber
Sir Write-a-Lot
|
Citat:
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...
__________________
Leadership is the art of getting people to want to do what you know must be done. Poslednja izmena od ivanhoe : 21. 03. 2006. u 05:38. |
|
21. 03. 2006. | #9 | |
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:
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. Poslednja izmena od jablan : 21. 03. 2006. u 09:21. |
|
20. 03. 2006. | #10 | |
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/ |
|
|
|
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. 14:09 |
Softver za pravljenje shema informacionog sistema | alex | Opušteno | 3 | 07. 02. 2008. 02:45 |
Zaštita podataka od pada sistema | Petar Marić | Opušteno | 7 | 23. 11. 2006. 12:59 |