Witam,

od kilku dni próbuję opanować logikę autoryzacji opartej na rolach. Niestety literatura dostępna jest właściwie tylko po angielsku, co tylko utrudnia zadanie . Studiując materiały binarycloud, nist.gov oraz tego, co streścił mi bela_666: wyciągnąłem następujące wnioski:

- uprawnienia (permissions) - są to konkretne zezwolenia na określone akcje typu dodawaj_artykul, edytuj_newsa czy usuwaj_komentarze

- role - są to obiekty witrualnie grupujące zezwolenia w jedną "całość". Przykładem może być rola "Administrator", "Moderator" itd.

-userzy - co to user wiadomo. Każdy user może być przypisany do określonej roli (lub na odwrót - rola może być ;przypisana do usera lub iluś tam userów). Dodatkowo do usera mogą być przypisane indywidualne uprawnienia.

No ale jakoś to za prosto dla mnie. To dla mnie przypomina zwykły system grup w forach dyskusyjnych

Poza tym zastanawiam się, co to są te obiekty. W MVC chyba to będą akcje prawda? (bo na mvc sie skupiam)

Jeszcze jedna kwesta: jak to technicznie rozplanowac. Tzn jak rozplanowac kolumny w bazie danych dla usera, zeby byla mozliwosc przypisania i roli i uprawnienia ( a czesto wiecej niz jednego)

ok, na razie tyle. Poproszę o konstruktywne odpowiedzi

ee tam skad ty uprawnienia wytrzasneles

masz poprostu role, które możesz przypisac użytkownikom, i jesli user posiada wszystkie role do wykonanie akcji jesrt przepuszczany dalej

dane o rolach dla akcji masz zapisane w konfigu ( db, xml, txt obojetnie )

bela_666: moze troche jasniej? bo te twoje opisy nie sa zbyt tłumaczące. Podaj jakies proste przykłady albo co

1 .pobierasz info o akcji ( wymagane role do jej uruchomienia, fallbacki, innne pierdoly )
2. kontroler przed uruchomieniem sprawdza czy user jest uwierzytelniony ( zalogowany )
3. jesli tak to pobiera jego role ( np. zserializowane dane w sesji )
4. sprawdza czy user posiada wszystkie role ktore sa wymagane do uruchomienia akcji ( moze miec wiecej rol, ale nigdy mniej )
5. jesli true przepuszcza dalej

a czy dla każdej akcji musze miec role? Bo przeciez wiadomo ze teoretycznie każdy user bedzie mogl ogladac newsy (zwyjatkiem zbanowanych ale to tutaj pomijam) wiec nie ma sensu robic do tego dodatkowej roli viewNews. Moim zdaniem role powinny być przypisane tylko dla tych akcji, które nie są dostępne dla ogółu np edytowanie newsa. W ten sposób zwykły user będzie bez żadnych ról, co byłoby równoznacze gdyby miał same role typu view np viewNews itd.

Pytam sie bo chce jakoś rozwiązać kwestię "gościa" w systemie. W powyższy sposób nie musiałbym mu przypisywać żadnych ról, byłoby prościej...

mam nadzieję że czytałes opis autoryzacji jaka jest w Phiendzie na php.pl - ja po przeczytaniu od razu załapałem o co chodzi;)

oczywiscie nie musi być ról dla akcji które moga być wywołanie przez każdego. Tylko pytanie czy kiedys nie będziesz chciał ograniczyć do nich dostępu.

kiedys czytalem o tym ale to bylo dawno i nieprawda Zara przeczytam jeszcze raz

Jezeli bede chcual ograniczyc dostep do jakijes akcji wystarczy ze w pliku config.xml wypelnie tag <requiredRoles> i juz

Ja robie to nastepujaco: kazda akcja, poza innymi danymi, ma ustawiony wymog logowania lub jego brak. Uzytkownik, ktory sprobuje wykonac akcje wymagajaca logowania jest cofany do ekranu logowania (a po poprawnym logowaniu - wykonuje akcje, jesli ma do tego uprawnienia); jezeli akcja nie wymaga logowania, to moze ja wykonac... i tak przeciez nie moge go zidentyfikowac.

Role (u mnie - grupy) pojawiaja sie pozniej, po zalogowaniu.

role to nie grupy, rola to pojedyncze uprawnienie, typu dodajNews, usunNews

ano tak tez mozna.

choc ja rzecz zawsze robilem ciut inaczej: user, grupa, nazwy dzialow i uprawnienia dla grup dla na kazdy z dzialow. uprawnienia zawsze mialem z zakresu <0-2> i tyle. 0 nawet nie byly zapiywane w bazie bo i po co? jesli wpisu na dany dzial nie ma na bazie to uprawnienie domyslnie przyjmuje wartosc na 0. 1 np. mogl w danym dziale roboc to i tamto etc. a 2 wszystko.