![]() |
![]() |
![]()
Post
#1
|
|
Grupa: Zarejestrowani Postów: 110 Pomógł: 0 Dołączył: 4.02.2003 Ostrzeżenie: (0%) ![]() ![]() |
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 |
|
|
![]() |
![]()
Post
#2
|
|
Grupa: Przyjaciele php.pl Postów: 698 Pomógł: 3 Dołączył: 28.03.2004 Skąd: Wrocław Ostrzeżenie: (0%) ![]() ![]() |
Nie chodzi o samo wywoływanie akcji, ale dostęp do niej. Poza tym rozwalając metody autoryzujące po nie wiadomo jakiej liczbie klas zwiększasz prawdopodobieństwo wystąpienia błędu, a w przypadku kontroli dostępu jest to problem krytyczny. Poza tym wywołanie metod statycznych w dynamicznym konktekście (nazwa akcji jest znana dopiero podczas wykonywania programu) jest nieeleganckie i na pewno nie polepsza jakości kodu.
Wyobraź sobie tą sytuację z własnymi newsami... Użytkownik posiada rolę editNews, ale akcja wymaga od niej jeszcze parametru "OWN". Kontroler autoryzacji nie wie w jaki sposób ma "zdobyć" ten parametr - on zna tylko statyczne, które są zapisane do bazy. Akcja podpowiada, że obiekt pomocniczy będzie wiedział co zrobić w tej sytuacji. Kontroler tworzy instancję klasy pomocniczej, a następnie prosi ją o wykonanie niezbędnych kroków. W tym przypadku obiekt pomocniczy wyciąga wiadomość z bazy, porównuje identyfikator użytkownika z identyfikatorem autora. Jeżeli wszystko się zgadza, to dopisywany jest parametr "OWN" do roli editNews. Dalsza część jest standardowa - sprawdzamy czy role się pokrywają i stwierdzamy, czy użytkownik może wywołać akcję. Zauważ, że kod klasy pomocniczej będzie miał zaledwie kilka linijek, a jego wykonanie będzie prawie niezauważalne pod względem wydajności (pomijając czas zapytania do bazy... ale przecież newsa nie trzeba pobierać drugi raz, dlatego można przechować go gdzieś, aby uniknąć ponownego wywołania tego samego zapytania). |
|
|
![]() ![]() |
![]() |
Aktualny czas: 7.10.2025 - 02:42 |