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

[ebe]

U mnie jest tak 3 akcje podstawowe, add, edit, delete. Każda akcja na obiekcie w danej (podanej w url) gałęzi drzewa (np. drzewo content lub members)

Mamy 3 akcje więc uprawnienia wyglądają tak

Kod

| id | obj_id |  node_id | type     |
| 1  | 304     | 1302      |    edit  |

Gdzie obj_id może być memberem, może być members_group, może być każdym dowolnym obiektem, bo umnie wszystko jest wirtualnie stworzonym obiektem na podstaiwe wirtualnej klasy (jak w ez<-love it) oczywiście type może być obcym kluczem do types jakiejś tabeli w db zawierającej różne akcje, node_id to prawo do danego węzła (i jego pod węzłów!) dziedziczene praw jest w logice. Prawa dziedziczone są nie tylko przez węzły ale też przez grupy użytkowników

W przyszłości

- zastosowanie NOT czyli zabronienie to pozwoli na wyłączenie praw do podwęzłów danym podgrupom
- mam specjalne akcje create_class, delete_class, add_role itp. chcę to ujednolicić i sprawić by nawet klasy były obiektami (!) podobnie z rolami czyli zostały by mi 3 akcje w cmsie add, edit, delete (IMG:http://forum.php.pl/style_emoticons/default/biggrin.gif) , klasy trzymałbym w kolejnym innym drzewie a role w specjalnym folderze danej grupy użytkowników, ale to wymaga zastanowienia i wymyślenia jak to ma działać i jak zrobić by działało szybko