DevProTalk

Forumi IT profesionalaca
web development, web design, e-business, SEO


Idite nazad   DevProTalk > Web dizajn i usability > Planiranje i usability
Želite da se reklamirate ekskluzivno na ovoj poziciji? Javite se

Planiranje i usability Planiranje, legalnost, privatnost, arhitektura, principi

Odgovori
 
Alati teme Način prikaza
Staro 20. 03. 2006.   #1
ivanhoe
Ivan Dilber
Sir Write-a-Lot
 
Avatar ivanhoe
 
Datum učlanjenja: 18.10.2005
Lokacija: Bgd
Poruke: 5.320
Hvala: 104
2.344 "Hvala" u 583 poruka
ivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svima
Pošaljite poruku preko Skype™ za ivanhoe
Default 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.
ivanhoe je offline   Odgovorite uz citat
Staro 20. 03. 2006.   #2
noviKorisnik
Dejan Katašić
Wrote a book
 
Avatar noviKorisnik
 
Datum učlanjenja: 10.06.2005
Lokacija: Novi Sad
Poruke: 1.017
Hvala: 129
86 "Hvala" u 43 poruka
noviKorisnik će postati "faca" uskoro
Default

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.
noviKorisnik je offline   Odgovorite uz citat
Staro 20. 03. 2006.   #3
marinowski
Igor Marinović
Expert
 
Avatar marinowski
 
Datum učlanjenja: 09.06.2005
Lokacija: Palić
Poruke: 549
Hvala: 31
39 "Hvala" u 17 poruka
marinowski is on a distinguished road
Pošaljite ICQ poruku za marinowski
Default

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.
marinowski je offline   Odgovorite uz citat
Staro 20. 03. 2006.   #4
jablan
VD IT Direktora
Invented the damn thing
 
Avatar jablan
 
Datum učlanjenja: 08.06.2005
Lokacija: Beograd
Poruke: 2.118
Hvala: 503
1.307 "Hvala" u 282 poruka
jablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamen
Default

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.

Poslednja izmena od jablan : 20. 03. 2006. u 15:19.
jablan je offline   Odgovorite uz citat
Staro 20. 03. 2006.   #5
ivanhoe
Ivan Dilber
Sir Write-a-Lot
 
Avatar ivanhoe
 
Datum učlanjenja: 18.10.2005
Lokacija: Bgd
Poruke: 5.320
Hvala: 104
2.344 "Hvala" u 583 poruka
ivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svima
Pošaljite poruku preko Skype™ za ivanhoe
Default

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...
__________________
Leadership is the art of getting people to want to do what you know must be done.
ivanhoe je offline   Odgovorite uz citat
Staro 20. 03. 2006.   #6
jablan
VD IT Direktora
Invented the damn thing
 
Avatar jablan
 
Datum učlanjenja: 08.06.2005
Lokacija: Beograd
Poruke: 2.118
Hvala: 503
1.307 "Hvala" u 282 poruka
jablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamen
Default

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.
jablan je offline   Odgovorite uz citat
Staro 20. 03. 2006.   #7
DejanVesic
old school
Professional
 
Avatar DejanVesic
 
Datum učlanjenja: 15.06.2005
Lokacija: Novi Beograd
Poruke: 448
Hvala: 21
70 "Hvala" u 46 poruka
DejanVesic će postati "faca" uskoro
Default

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.
__________________
http://www.vesic.org | Blog: http://www.vesic.org/blog/ | Fina kolekcija programa: http://www.vesic.org/programi/
DejanVesic je offline   Odgovorite uz citat
Staro 20. 03. 2006.   #8
marinowski
Igor Marinović
Expert
 
Avatar marinowski
 
Datum učlanjenja: 09.06.2005
Lokacija: Palić
Poruke: 549
Hvala: 31
39 "Hvala" u 17 poruka
marinowski is on a distinguished road
Pošaljite ICQ poruku za marinowski
Default

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.
marinowski je offline   Odgovorite uz citat
Staro 20. 03. 2006.   #9
DejanVesic
old school
Professional
 
Avatar DejanVesic
 
Datum učlanjenja: 15.06.2005
Lokacija: Novi Beograd
Poruke: 448
Hvala: 21
70 "Hvala" u 46 poruka
DejanVesic će postati "faca" uskoro
Default

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.
__________________
http://www.vesic.org | Blog: http://www.vesic.org/blog/ | Fina kolekcija programa: http://www.vesic.org/programi/
DejanVesic je offline   Odgovorite uz citat
Staro 20. 03. 2006.   #10
Ilija Studen
Direktor Kombinata
Invented the damn thing
 
Avatar Ilija Studen
 
Datum učlanjenja: 07.06.2005
Poruke: 2.669
Hvala: 44
119 "Hvala" u 64 poruka
Ilija Studen će postati "faca" uskoroIlija Studen će postati "faca" uskoro
Default

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 (
  
=> 
  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.

Poslednja izmena od Ilija Studen : 20. 03. 2006. u 20:22.
Ilija Studen je offline   Odgovorite uz citat
Odgovori



Pravila pisanja
Možete ne započinjati nove teme
Možete ne slati odgovore
Možete ne slati priloge
Možete ne izmeniti svoje poruke
vB kôd je Uključen
Smajliji su Uključen
[IMG] kod je Uključen
HTML kôd je Isključen
Pogledajte forum

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


Vreme je GMT +2. Trenutno vreme je 01:36.


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.