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]

Nic nie jest na stałe zakodowane. Wpisy do bazy wymagają tylko lekkiej zmiany. Standardowo robimy tak:

Kod

Akcja:
name = actionName
neededGroups = groupOne, groupTwo

Zmieniamy na taki kod

Kod

neededGroups = groupOne($param1, const, 1);groupTwo

Kontroler wie, że $param1 określa wartość parametru o nazwie "param1" przekazywanego do akcji. "const" do stały łańcuch znakowy, do którego będziemy porównywać parametry ról użytkownika.

Skąd kontroler ma wiedzieć jakie są parametry akcji? To proste, u mnie silnik jest zaprojektowany podobnie do phienda2. Na początku router tworzy na podstawie żądania http obiekt kontekstu, w którym przechowujemy m.in. nazwę akcji oraz jej parametry. Następnie wywoływane są filtry zgodnie z wzorcem Intercepting Filter. To każdego filtru trafia obiekt kontekstu i to na nim są dokonywane zmiany. Z niego wiemy o nazwie akcji oraz jej parametrach. Jeżeli coś nam w filtrze nie pasuje, to modyfikujemy te dane. Wystarczy stworzyć authorizingFilter i wkomponować w niego kontroler dostępu. Jak będzie czas to wezmę się za to, w tej chwili szukam czasu, żeby tutaj coś napisać i odpocząć. Koniec semestru, męczą nauczyciele...

Jaki interfejs dostanie administrator strony (nie programista)? To też nie jest problem, trzeba tylko umieć odpowiednio złożyć wszystko do kupy. Przynajmniej ja nie widzę w tym problemu. Oczywiście jeżeli chcesz mieć dokładnie wszystko dostępne bez ingerencji bezpośredniej do kodu/bazy, to trochę roboty będzie. Ale jak chciałbyś zrobić to bez parametryzowania? Obsługa specjalnej grupy to jest ingerencja w kod kontrolera/akcji, a tego nie chcemy... Raz zakodowany elastyczny system sprawdzi się lepiej niż system z licznymi wyjątkami. Zauważ, że przy parametryzowaniu takie dziwne sytuacje to norma. Po tym co przeczytałem o twoim rozwiązaniu taki użytkownik byłby wyjątkiem. A im więcej wyjątków tym więcej kodu, więcej miejsc, w któreych możesz popełnić błąd, zwiększenie stopnia złożoności... Nie widzę żadnych korzyści.

Tak więc jak mówiłem... Znajdę trochę czasu to przedstawię jakąś wersję powiedzmy samego panelu do administracji uprawnieniami, jak mówiłeś to by cię najbardziej interesowało. Zasadę działania kontrolera opisałem post wcześniej, więc z implementacją nie powinno być problemu.