kontrola dostepu Opcje

[evo]

Witam,


Chial bym rozpoczac dyskusje na temat w jaki sposob projektuje sie system z kontrola dostepu.

Osobiscie jestem na etapie mojego pierwszego projektu ,ktory wymaga wiecej niz dwoch stanow (admin, user), wymaga on grup o roznym zakresie dostepu do systemu

Zabardzo nie wiem jak sie do tego zabrac.

Sam moj system/jadro laduje odpowiednie wtyczki,ktore sa odpowiedzialane za dostep do danych. Do tej pory kontrolowalem dostep na polacie wyboru akcji, bo kazdy plugin choc do innei zawartosci obsluguje te same akcje (add,remove,edit,show) wiec po wyborze wtyczki lecz przed wyborem akcji sprawdzalem czy uzytkownik ma prawo do tego, lecz teraz potrzebje wiekszej wolnosci tzn. niektorzy moga miec dostep do czegos do czego inni nie i na odwrot.

I zastanawiam sie czy nie przeniesc kontroli dostepu do samych akcji dostepu do danych, czy moze lepiej wymagac od wtyczki by opisala kto ma do jakich akcji dostep a sama kontrole zostawic w jadrze.




Wszelkie uwagi i pomysly sa mile widziane jak i wszelkiego rodzaju materialy, ktore wcale nie musza byc oparte na przykladach php, lecz duzym plusem by bylo gdyby opisywaly schemat kontroli dostepu w aplikacjach web. Jezyk Niemiecki,Angielski lub Polski.

Z gory dziekuje i pozdrawiam
evo

[Ludvik]

A co jesli uzytkownik ma miec mozliwosc tylko edycji swoich newsow ?
Pozatym robi sie problem kiedy mamy np. forum i trzeba nadawac prawa moderacji ? Macie na to jakis pomysl poza pisaniem osobnego accessController-a ?

Słuszna uwaga. Można wprowadzić parametryzowane role/grupy. Role były by opisywane przez parametry, dzięki czemu można by było przekazać dodatkowe informacje.

Załóżmy, że mamy grupę moderatorów "mods" i 10 różnych for. Chcemy nadać konkretnemu użytkownikowi możliwość moderacji for 2, 5 i 9. Dopisujemy go do grupy mods, ale podajemy identyfikatory for. Można to formalnie zapisać jako mods(2,5,9).
Jak użytkownik ma majstrować tylko przy swoich newsach, to zapisujemy go do grupy newsEditors(only_own). Jeżeli ma mieć prawo do wszystkiego to możemy zapisać to jako rola(*). Problem od strony użytkownika można rozwiązać w ten sposób. Teraz co z akcjami? Myślę, że można przyznać akcjom dostęp do parametrów akcji. Wtedy możemy porównywać konkretne parametry akcji z parametrami grup/ról. Ja przynajmniej tak to widzę.

Gdzieś to rozwiązanie jest używane, wystarczy wstukać w googlarce "parametrized role based access control".

Halfik:
Co do twojego podejścia, to przynaję ci rację. Nie chce mi się za dużo pisać, bo w 99% popieram.

Jaki problem widzę w przechowywaniu dużej ilości danych? Przy każdym żądaniu trzeba je odczytać, przeparsować plik sesyjny, potem zapisać. Miejsce też zajmują te dane. Niby duża strona będzie potrzebowała mocy i miejsca, ale kto uruchamia większe projekty na słabych serwerach?

Nie są to duże koszta, ale jednak są. Chociaż dobrze rozplanowany system będzie wolny od tej wady...

Acha... Co do pojedynczych ról: Myślę, że takie rozwiązanie przydaje się jednak czasem. Są to skrajne przypadki, ale jak sam powiedziałeś "nawet jesli nie potrzebujesz wiecej, to dlaczego sobie zamykac pewne drogi na przyszlosc?". Jak nie będziesz potrzebował, to po prostu nie będziesz przypisywał pojedynczych ról. Ogólnie tworzenie grupy z jedną rolą dla jednego użytkownika moim zdaniem mija się z celem, przerost formy nad treścią.