![]() |
![]() ![]() |
![]() |
![]()
Post
#1
|
|
Grupa: Zarejestrowani Postów: 6 Pomógł: 0 Dołączył: 30.11.2007 Ostrzeżenie: (0%) ![]() ![]() |
Witam!
Od pewnego czasu poznaje mvc i natrafiłem na ciekawy tutorial na http://www.phpit.net/article/simple-mvc-php5/ . Bardzo mi podeszło to co tam jest przedstawione - myśle, że na początek jest idealne. I, że będe to mugł (mvc) wykorzystywać jako podstawe w kolejnych aplikacjach PHP. Ale do rzeczy, przechodząc przez ten tutorial - przerabiając cześciowo itp. , zastanawia mnie jeden fakt... Jak zrobić dosęp do panelu administracyjnego , chciałbym to zrobić w ruterze no i właśnie, nie za bardzo wiem który z pomysłów wybrać. Mam dwa pomysły na dzień dzisiejszy - jeden to sytuacja w którym sprawdzany jet czy podkatalog w sciezce jest katalogiem administracyjnym np:
Powyższa sytuacja zdaje się być dobra gdy użytkownika zaogowany to admin i nikt więcej. Drugie rozwiązanie to system praw zapisywanych/odczytywanych z bazy danych (zserializowana tabela). W ruterze wykonywana by była funkcja mapująca (ja to tak widze) - sprawdzająca otrzymaje prawa z powiązaniami prawo - kontroler. Jeśli ktoś się zastanawia o co mi chodzi, to chodzi o to czy ma ktoś jakies inne pomysły na rozwiązanie tego zadania, które można by tak w około >80% używać w przyszłości. Pozdrawiam. |
|
|
![]()
Post
#2
|
|
Grupa: Zarejestrowani Postów: 487 Pomógł: 7 Dołączył: 7.01.2004 Skąd: Warszawa Ostrzeżenie: (0%) ![]() ![]() |
W ruterze wykonywana by była funkcja mapująca (ja to tak widze) - sprawdzająca otrzymaje prawa z powiązaniami prawo - kontroler. Tworzysz odrębną klasę do sprawdzania uprawnień, następnie przekazujesz referencje do FrontController-a i w nim weryfikujesz czy user ma prawo do akcji.
|
|
|
![]()
Post
#3
|
|
Grupa: Zarejestrowani Postów: 6 Pomógł: 0 Dołączył: 30.11.2007 Ostrzeżenie: (0%) ![]() ![]() |
Podoba mi sie to rozwiązanie, zaraz je przetestuje.
Ten post edytował mma 5.12.2007, 11:41:56 |
|
|
![]()
Post
#4
|
|
Grupa: Zarejestrowani Postów: 879 Pomógł: 189 Dołączył: 14.06.2006 Skąd: Bytom Ostrzeżenie: (0%) ![]() ![]() |
@splatch, mam pytanie do Ciebie i do Twojego przykładu. Takie rozwiązanie jak zaprezentowałeś sprawdza się gdy chodzi o stały dostęp do jakieś akcji. Jak byś rozwiązał tutaj dynamiczny dostęp do akcji, np. user może dodawać artykuł, ala edytować go mogą administratorzy, moderatorzy i user, który dodał ten artykuł. Gdzie to sprawdzać?? W SecureAction::getCredentials() pobierać dane z modelu??
|
|
|
![]()
Post
#5
|
|
Grupa: Zarejestrowani Postów: 487 Pomógł: 7 Dołączył: 7.01.2004 Skąd: Warszawa Ostrzeżenie: (0%) ![]() ![]() |
Jeśli idzie o sprawdzanie uprawnień na takim stopniu można rozszerzyć interfejs o metodę isAuthorized, która odczyta rekord i zweryfikuje czy dana osoba ma uprawnienia do danego rekordu. Jest to poniekąd już fragment logiki aplikacji. Zazwyczaj w takim przypadku tworzyłem oddzielną akcję:
|
|
|
![]()
Post
#6
|
|
Grupa: Zarejestrowani Postów: 793 Pomógł: 32 Dołączył: 23.11.2006 Skąd: Warszawa Ostrzeżenie: (0%) ![]() ![]() |
Ogólnie edycję bym rozdzielił od widoku... wtedy nie ma tego problemu.
Pojawia się natomiast gdy mamy nałożone ograniczenie na dostęp do np. artykułów, gdy użytkownik ma dostęp tylko do pewnej puli. Ponieważ można to dopiero zweryfikować mając dane artykułu. Bo np. to co przestawił splatch ma pewną wadę pobiera dwa razy te same dane. Można by było np. - sprawdzanie ogólnego dostępu do akcji - inicjalizacja, pobranie danych - sprawdzenie dostępu do danych danych. Ja to rozwiązywałem w kodzie akcji przez przekazanie odpowiednich danych do obiektu autoryzacji. Ale u mnie po prostu różne rzeczy (coś jak posty, komentarze, artykuły) mają wspólną grupę na której to podstawie jest dostęp ustalany. Tylko się tak zastanawiam czy tworzyć abstrakcję (w tej metodzie co splatch proponuje) klas akcji z autoryzacją, czy mieć niezależny obiekt autoryzujący. Bo np. jak ktoś nie ma dostępu, ładuje się tylko inny szablon, gdzie jest np. tylko tytuł artykułu i formularz logowania. |
|
|
![]()
Post
#7
|
|
Grupa: Zarejestrowani Postów: 487 Pomógł: 7 Dołączył: 7.01.2004 Skąd: Warszawa Ostrzeżenie: (0%) ![]() ![]() |
Sedziwoj nie musimy mieć do czynienia z dwoma zapytaniami. Ponieważ wiemy, że metoda isAuthorized zostanie wykonana wcześniej możemy przypisać wynik do pola w danej klasie i normalnie odczytać w execute.
W skrajnym wypadku można stworzyć kolejny miks - SecurityManager, który potrafi również autoryzować dostęp do obiektów. Wówczas akcja zwracała by typ obiektu a SecurityManager na podstawie dostarczonych informacji sprawdzałby co użytkownik może zrobić. |
|
|
![]()
Post
#8
|
|
Grupa: Zarejestrowani Postów: 793 Pomógł: 32 Dołączył: 23.11.2006 Skąd: Warszawa Ostrzeżenie: (0%) ![]() ![]() |
Liczyłem że zostanie skrytykowana (pozytywnie lub nie) metoda autoryzacji dostępu do treści w kodzie akcji, może się jeszcze doczekam.
Co do metody isAuthorized() to trochę jednak mnie zastanawia, ponieważ czasem zanim dostaniem się do danych nam potrzebnych do autoryzacji musimy wydobyć inne, a wtedy metoda nie robi tylko tego co powinna. Do tego sprawdzenia
powinny być nie na tym poziomie, tylko obiekt autoryzacji to powinien wiedzieć, przekazujemy autora i mamy boolean, nie obchodzi nas czy ma dostęp bo jest adminem czy dlatego że jest autorem. Do tego nie wiemy co mamy robić kiedy ktoś nie ma dostępu do treści, przy edycji to jest raczej oczywiste, przy podanym przeze mnie przykładzie dostępu do artykułu już nie. Ponieważ nie chcemy nic robić więcej niż wyświetlić inny szablon. Oczywiście ta metoda mogła by go zmienić i zwrócić true ale to moim zdanie mijanie się z celem. Sam nie jestem do niczego przekonany, więc chętnie wysłucham wszelkich konstruktywnych uwag. |
|
|
![]()
Post
#9
|
|
Grupa: Zarejestrowani Postów: 487 Pomógł: 7 Dołączył: 7.01.2004 Skąd: Warszawa Ostrzeżenie: (0%) ![]() ![]() |
Liczyłem że zostanie skrytykowana (pozytywnie lub nie) metoda autoryzacji dostępu do treści w kodzie akcji, może się jeszcze doczekam. Co do metody isAuthorized() to trochę jednak mnie zastanawia, ponieważ czasem zanim dostaniem się do danych nam potrzebnych do autoryzacji musimy wydobyć inne, a wtedy metoda nie robi tylko tego co powinna.
Do tego sprawdzenia powinny być nie na tym poziomie, tylko obiekt autoryzacji to powinien wiedzieć, przekazujemy autora i mamy boolean, nie obchodzi nas czy ma dostęp bo jest adminem czy dlatego że jest autorem. Nie sądzę byś miał tutaj rację: - Skąd SecurityManager ma wiedzieć, że ta akcja operuje na takich czy też innych obiektach? - W jaki sposób ma odczytywać obiekty? W końcu to nie jest brocha SM. - Co jeśli SecurityManager ma się zachowywać różnie w zależności od akcji? To znaczy są zmiany w sposobie dostępu do tego obiektu. Osobiście pracuję w kodzie, w którym to SecurityManager ma wiedzieć czy ktoś ma dostęp do obiektu i wierz mi, jest sieczka. Są cztery klasy, każda gromada metod statycznych tylko po to by sprawdzić isUserAuthorizedForApprove(Application, Client, User). Do tego urosły wielkie utile, które są głównie używane w owych managerach. Do tego nie wiemy co mamy robić kiedy ktoś nie ma dostępu do treści, przy edycji to jest raczej oczywiste, przy podanym przeze mnie przykładzie dostępu do artykułu już nie. Ponieważ nie chcemy nic robić więcej niż wyświetlić inny szablon. To co przemawia za tym by ten kod był właśnie w akcji to to, że akcja wie z czego będzie korzystać i z nikim innym nie musi się tym dzielić. Mylisz się twierdząc, że akcja nie wie jak zachować się w przypadku błędu z dostępem do obiektu. Może albo wywalić wyjątek, powiedzmy new UnauthorizedObjectAccessException(object $type) a jego obsługę zrzucić na kark FrontController-a albo przekierować na odpowiednią stronę (tu dodajemy metodę do interfejsu).
W skrajnym wypadku można wywalić CustomAuthorizationAction i pójść w abstrakcje:
Oczywiście nie jest to jedyne rozwiązanie, fakt faktem zgłoszone uwagi wymagały rozbudowania przykładu podanego na początku. Inny pomysł jaki przyszedł mi do głowy to tworzenie delegatów, które by się przekazywało do SecureManagera. |
|
|
![]()
Post
#10
|
|
Grupa: Zarejestrowani Postów: 793 Pomógł: 32 Dołączył: 23.11.2006 Skąd: Warszawa Ostrzeżenie: (0%) ![]() ![]() |
Właśnie o taki komentarz mi chodziło (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)
Jeszcze muszę sobie pomyśleć nad tym, ale zauważ jedno, że druga propozycja klasy CustomAuthorizationAction niewiele różni się od tego co ja podałem. A to dlaczego? Bo w isAuthorized() pobierasz dane, potem w execute() sprawdzasz do nich dostęp, przy braku wywołujesz getAuthErrorView(), a przy powodzeniu doExecute(). Ale ogólnie jest ciekawe rozwiązanie, bo rozbijamy działanie na parę metod, które robią pewne fragmenty. Mimo wszystko bym dodał metodę init() (czy jak jakkolwiek zwać) która by pobierała dane potrzebne do wywołania isAuthorized(), aby ta metoda nie robiła nic więcej niż sprawdzała czy ma dostęp. |
|
|
![]() ![]() |
![]() |
Aktualny czas: 14.09.2025 - 17:53 |