Forum PHP.pl

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

Nauczyłem się używać i będę polecał: F-L-A-G-I.
Polecam ten art. bardzo fajnie napisany, mający dobre przykłady.
pozdrawiam

Osobiście stosuję autoryzację opartą na grupach i rolach. Każdy użytkownik może posiadać określone role i przynależeć do różnych grup.

Akcja wymaga posiadania wszystkich ról lub bycia w jednej z określonych grup.

Na przykład mamy administratora i newswritera. Admin należy tylko do grupy "admins", a newswriter może tylko pisać newsy, dlatego dostaje tylko role NewsWriter, NewsEditor etc... Akcja wpisywania wiadomości wymaga przynależności do grupy admins lub posiadania roli NewsWriter. Wszystko ładnie da się zapisać używając podstawowych funkcji tablicowych.

Wydaje mi się, że elastyczność i poziom bezpieczeństwa są wystarczające. Uprawnienia możesz sprawdzać tylko przed wykonaniem pierwszej akcji, kłania się wzorzec Intercepting Filter.

Role i grupy użytkowników trzymamy razem z ich danymi, a wymagania akcji w konfiguracji.

Nie będzie też problemu z blokowaniem dostępu dla określonych grup/ról...

coś podobnego miałem na myśli.

[PHP] pobierz, plaintext 
<?php
define('banned', 0);
define('member', 2);
# etc.
 
class AuthorizeMember implements IAuthorize {
public function __contruct( $flag ) {
if($flag & banned) $this->set(banned);
}
 
public function set( $f ) {
$this->memberAuthorize = $f;
}
 
public function get() {
return $this->memberAuthorize;
}
}
?>
[PHP] pobierz, plaintext 

Dla akcji:

[PHP] pobierz, plaintext 
<?php
class AuthorizeAction implements IAuthorize {
public function __construct($action ) {
$this->action = $action;
}
public function set($f) {
$htis->conn->executeUpdate('UPDATE actions SET authorize='.$f.' WHERE name='.$this->action.'');
}
 
public function get() {
$w = $this->conn->execute("SELECT authorize FROM actions WHERE name='".$this->action."'");
return $w->next();
}
 
public function check($m) {
return ($this->get() == $m) ? true : false;
}
}
?>
[PHP] pobierz, plaintext 

Sprawdzić można bardzo prosto:

[PHP] pobierz, plaintext 
<?php
class delete extends action {
public function __construct(AuthorizeAction $action) {
if($action->check($this->memberAuthorize->get())){ throw new TException(get_class($this) .': False') }
}
}
?>
[PHP] pobierz, plaintext 

pozdrawiam

Ten post edytował Ociu 4.12.2005, 09:17:40

Co do twojego kodu:

Ja bym nie dopuścił akcji do manipulacji przy autoryzacji, przenosisz część odpowiedzialności na akcje i tworzysz kolejne miejsce, w którym możesz błąd popełnić.

Jeżeli użytkownik nie ma prawa do uruchomienia akcji, to nawet nie powinien zostać stworzony jej obiekt. Filtr nie może przepuścić tej akcji, łatwiej jest zmienić w żądaniu nazwę akcji na chociażby "NoAuthorizationAction", która powiadomi użytkownika o braku odpowiednich uprawnień.

Gdzie później łapiesz ten wyjątek i co z nim dalej robisz? Brak uprawnień jak dla mnie nie jest sytuacją wyjątkową, tylko sygnałem, że trzeba pójść inną ścieżką akcji.

A co się stanie jak będziesz miał 50 akcji i zajdzie potrzeba zmiany interfejsu autoryzacji? Domyślam się, że to jest mało prawdopodobne, ale akcje są uzależnione od konkretnej implementacji systemu uwierzytelniania. Rozumiem, że na twoje potrzeby to rozwiązanie spełnia w 100% swoje zadanie, dlatego to jest taka mała uwaga.

Mam troszeczke inne podejscie, wiekszosc uprawnien stosuje na poziomie bazy danych, bo tak jak pisal @Ludvik kazdy byla w akcji moze spowodowac dostep do akcji. Tam gdzie sie nie da lub projekt nie moze byc oparty na uprawnieniach baz danych uprawnienie jest sprawdzane zanim wywolywana jest akcja.

To tylko przyład. Nie będę się rozpisywał, aby nie tworzyć zbędnej dyskusji.
pozdrawiam

ja takie rzeczy tez robie w oparciu o grupy i role.
grupom nadaje sie role/uprawnienia a usera przypisuje do grupy lub kilku grup.
jesli ktora z grup ma uprawnienia do podjecia jakiejs tam akcji uzytkownikowi sie na nia zezwala, nawet jesli w 1 grupie akacja jest zabroniana a w innej dozwolona. powiedzmy ze zezwolenia maja wyzszy priorytet.

w razie gdy userowi trzeba uprawnien nad grupe, mozna powolac specjalna grupe tylko dla niego i jej nadac odp role. albo do systemu wprowadzic jakiegos rodzaju wyjatki. znaczy sie ze niektorzy uzytkownicy procz uprawnien wynikajacych z grup moga posiadac specyficzne dla siebie tylko uprawnienia ktore beda nadrzedne nad uprawiena grupowe.

Ja bym wyróżnił zabranianie od braku uprawnień... Jeżeli mówisz, że jedna grupa nie posiada ról potrzebnych do wykonania akcji, a druga je posiada, to jest prawidłowe zachowanie. Natomiast kiedy jedna grupa zabrania wykonania akcji, a druga wycofuje to, to według mnie nie jest najlepsze wyjście... W zasadzie zabranianie dostępu powinno mieć wyższy priorytet niż role zezwalające. Raczej blokowanie dostępu powinno być używane tylko tymczasowo i do blokowania większej ilości grup/ról. Chcesz wyciąć jedną rolę to po prostu usuwasz ją, a jeżeli chcesz nie dopuścić użytkownika do całej strony, wtedy usuwanie wszystkich uprawnień może stać się uporczywe, jeżeli chcesz je przywrócić.

Przypisywanie ról do grup... hmmm... myślałem nad czymś takim, ale się wycofałem i obecnie sama przynależność do grupy jest dla mnie jakąś rolą. Grupy wprowadziłem, aby iść na skróty: Po co mam wpisywać adminowi role addNews, editNews, removeNews, addArticle etc., skoro mogę go przyłączyć do grupy admins i nie pisać już tych ról? Rozumiem, że w twoim przypadku grupa admins może mieć jedną rolę np. doAll, ale to się moim zdaniem mija z celem - nazwa grupy jest wystarczająca do identyfikacji uprawnień. Po to zbieramy uprawnienia w grupy, aby potem nie pracować na xxx rolach.

Halfik: Jak przechowujesz dane o uprawnieniach?

Pozdrowienia...

tak zgadza sie, blokowanie powinno miec wyzszy priorytet nad zezwolenia - tak jest wszedzie i nie ma co plynac pod prad, tak ma chociazby ip-tables i cala reszta zabawek na linkach. wiec ok - zezwolenia sa podrzedne wzgledem accessow.

ale jak sie zastanowic nie zawzsze konieczne jest wprowadzanie zabraniania czegos. wystarczy ze user nie ma uprawnien i po sprawie. chociaz pewnie zdarza sie systemy, w ktorych zabranianie wykonywania czynnosci moze sie przydac - chociaz nie mam pomyslu gdzie. bo gdybysmy chcieli z jakiegos powodu "ukarac" usera to mu usuwamy uprawnienia. hmmm...

w sumie mozna tak jak na ip-tables, jesli piszemy jakis system ktory wymaga powaznej kontroli tego co moga i co robia userzy - nie wiem gdzies w bankowosci or something - nie mam pomyslu. ale mniejsza o to. chodzi o to, jak sie konfiguruje frewalla zeby byl bezpieczny. pkt 1. blokujesz wszystko i wszystkim, a pozniej zezwalasz na grupom na rozne akcje jak juz userzy zaczna plakac ze czegos nie moga zrobic jest troche roboty, ale to gwarancja dobrze skonfigurowanego firewalla - podobna strategie pewnie mozna gdzies wykozsytac w php - tylko gdzie ? i have no idea



nie nadawalbym grupie adminow takiej roli. raczej preferowalbym role powiedzmy hmmm... podstawowe, a nie role totalnej wladzy i jak cos to nadaje adminom wszystkie role podstawowe.

a wprowadzenie grup jest konieczne jesli powaznie myslimy o zarzadzaniu uprawnieniami userow - grupy masz teraz na chyba all systemach operacyyjnych - i to nie jest przypadek. wyobraz sobie np 5000 userow i ze kazdego bys mial pilnowac czy ma takie uprawnienia jakie powinnien miec - no masakra. albo jak nagle sie okaze ze - tutaj zalozmy ze to jakis system w duze firmie - ze pracownicy wydzialu finansow potrzebuja uprawnien do czegos tam - i jest ich np. 50 - po cholere ich szukac i kazdemu z osoba - jest grupa finanse jeden klik i po sprawie, ale to wszyscy wiemy.

a co do traktowania samej grupy jako juz jakiejs roli hmm... mozna, ale czy nie lepiej czarne zostawic czarnym a biale bialym? lepsza wieksza czytelnosc. jak zrobisz z grupy juz jakies prawo, to jak pozniej ktos sie dorwie do kodu, moze sie z tym dziwnie poczuc nim sie polapie pracownik nalezacy do grupy "dzial finanse" moze wykonac operacje X bo sama przynaleznosc do tego dzialu juz daje mu odp uprawnienie. sa grupy i sa role i ja raczej wolalbym zeby ich nie mieszac.


chodzi Ci o to jak to przechowuje na bazie? no kazdy user ma powiazanie z tabela grup - jest to powiazanie typu jeden->wielu - czyli 1 user moze nalezec do N grup. dalej masz table zdefiniowanych rol. grupy sa powiazane z rola dokladnie jeden->wielu. i to chyba tyle.

Sytuacja jest taka: banowanie i odbanowywanie. Masz użytkownika, który ma jakiś niepowtarzalny zestaw ról, który jest trudno przywrócić. Wtedy wygodniej jest wprowadzić rolę banned niż usuwać całą listę roli. Jak będziesz chciał mu przywrócić uprawnienia to co zrobisz? Nie widzę innego logicznego rozwiązania.



To jest po części prawdziwe przy każdym systemie bazującym na rolach. Wyjątkiem są akcje, które nie wymagają ani jednej roli i grupy.

Co do grup to nie zrozumieliśmy się chyba. Grupy są na pewno potrzebne, tylko pytanie w jakiej formie? Ja mówię, że grupy mogą istnieć jako niebezpośrednie połączenie kilku ról. To znaczy, że wciąż istnieje podział na grupy i role (żeby nie obniżać elastyczności), ale grupy nie posiadają ról. Chcemy aby ktoś mógł tylko dodawać newsy, wtedy dostaje rolę addNews. Dzięki temu nie usunie go, ani nie zmodyfikuje. Jeżeli chcemy mieć "news admina", wtedy włączamy go do grupy newsAdmins. U ciebie ta grupa by posiadała role addNews, editNews, removeNews etc... U mnie po samej nazwie grupy można identyfikować co użytkownik może a co nie.

Twoje rozwiązanie cechuje trochę większa elastyczność, ale musisz te dane gdzieś zapisać, a przy dużej ilości użytkowników, ról, grup, akcji może to być uciążliwe. Ja zwalam odpowiedzialność na projektanta, żeby przemyślał dokładnie podział odpowiedzialności. Wypadało by zastanowić się kiedy to się sprawdza, a kiedy nie. Dzisiaj chyba za późno dla mnie, jutro szkoła jeszcze...

Co do przechowywania danych - źle zadałem pytanie. Chodzi mi o pobieranie ról z grup i przenoszenie wszystkich odpowiedzialności pomiędzy żądaniami. Pewnie masz tablicę z rolami zapisaną w sesji i ciekawi mnie jak sobie radzisz z dużą ilością użytkowników posiadajacych dużą ilość ról.

Jak wygląda u ciebie sprawa nietypowych użytkowników - gościa i administratora?

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 ?

tak jesli mowimy o systemach w ktorych uzyteczne jest tymczasowe blokowanie userow to bez sensu by bylo cos usuwac zeby to za jakis czas znowu dodawac/ustawiac.


jesli dobrze zrozumialem chcesz miec grupy rol - zeby nie przypisywac userowi kazdej z nich osobo, oraz pojedyncze role, gdy user nie potrzebuje wiecej jak 1 roli - co sie moze zdarzyc.

bo widzisz mojde podejscie jest nieco inne. grupa jest dla mnie jakas tam podstawowa jednostka organizacyjna - pakuje userow w paczki. sam user dla mnie nie ma uprawnien. uprawnienia maja grupy do ktorych on nalezy. to gwarantuje spora przejrzystosc calosci.

wiec: ja chce miec grupy opisane przez role. zas Ty chce miec grupy rol. hmmm...
to prawie to samo. przy czym to podejscie do ktorego ja sie przykleilem jak zauwazyles jest bardziej elastyczne i daje ciut wieksze mozliwosci. jesli porobisz grupy opiszesz je rolami i do grup przydzielisz userow, to procz tego ze userzy maja to czego chcesz - jakies uprawnienia, to ulatwiasz sobie zarzadzanie userami.

zreszta nie bardzo mi sie podoba ze chcesz miec zarowno grupy rol jak i pojedyncze role. zalozmy ze bedziesz mial ciut tych userow w systemie. ze ich liczba bedzie rosla w czasie. i tak zalozmy co pare dni bedziesz zmuszony przydzielic np. 1-10 userom pojedyncze uprawnienie, za pare dni to samo i znowu. gdybys nawet mial grupe ktora jest opisana tylko przez pojedyncza role - po prostu dodajesz usera do grupy i sie dalej tym nie martwisz. niby to samo. ale... co jesli bedzie trzeba w jakis sposob zmienic ta role, usunac albo cos? bedziesz musial ja odebrac N userom kazdemu z osoba - ja tylko sciagne ja grupie. i jeszcze: a co jesli za jakis czas bedziesz musial dodac userom ktorzy moga dodac np. tego newsa role do np. usuwania i edycji newsow? bedziesz musial usunac im ta pojedyncza role i przypisac im grupe rol "newAdmin" - dobrze rozumuje? jesli tak to troszke to malo wygodne.

generalnie nie przekonuje mnie to Twoje rozwiazanie. nawet jesli nie potrzebujesz wiecej, to dlaczego sobie zamykac pewne drogi na przyszlosc? zostane przy swoim i bede sie upieral ze userzy do grup a grupy opisane przez role.



to rozwiazanie sie sprawdza od dziesiecioleci - zauwaz ze wszyskie dystrybuje linuxow z niego korzysaja od zarania dziejow. nawet ms w koncu to docenil i w winach xp czy 2k juz masz podobne rozwiazania.

co do przechowywania danych - jesli user sie loguje do systemu - sciagam z bazy info o jego uprawnieniach i trzymam na sesji, zadne nowum. generalnie jak mamy obiekt np. new zakladam ze obiekt wie jakie trzeba miec role zeby wymusic na nim dane operacje. wiec sprawdzamy na bazie grupy usera i sciagamy role ktorymi te jego grupy sa opisane i ladujemy na sesje.

i nie rozumiem problemu z duza iloscia uzytkownikow. martwisz sie o obciazenie bazy? czy czego?


hehe no wlasnie
a jaki upatrujesz problem w duzej ilosci userow z duza iloscia praw?


jesli idzie o goscia to nie nalezy do zadnych grup - zatem nie ma rol. ale... jesli do przegladania czegos co gosc powinien przegladac sa potrzebne juz role - to mozna zrobic grupe Goscie opisac je tymi podstawowymi rolami i jesli ktos wchodzi na www - bo zgaduje ze o tym rozmawiamy - automatycznie zostaje potraktowany jak czlonek grupy goscie, jesli sie zaloguje - zmieniaja sie jego grupy i role. w sumie to bedziemy mieli grupe ktora de facto nie ma zadnego usera hehe.

a jesli chodzi o admina. mozna porobc rozne rodzaje adminow. tych najwyzszych, pol-adminow, adminow jakis sekcji itd. - tworzysz grupy i nadajesz im all mozliwe role, czy np 75% moziwych rol - co Ci trzeba.



ja bym zrobil dla samych tylko newsow: grupe adminow - moga all, grupe pol adminow - moga all na swoich newsach - i pozniej przydziela usera do odp. grupy. a nadawnie praw do dodawnia newsow bez mozliwosic edycji troszke moja sie z celem. ale jesli ktos chce pewnym userom pozowlic dodawac i edytowac ale juz nie usuwac - robi sobie 3 grupy zwiazana z newsami i przypisuje jej te 2 role, a usera do grupy.

no forum tak samo jak wszystko inne. grupy i role. tylko ze takie forum z prawdziwego zdarzenia to mody ktore moga cos na jakiejs tam tylko czesci forum. hm... no ale im wiecej takich czesci forum tym wiecej rol i nic poza tym. czyli zrobi sie np. grupe adminow - nada jej all role zwiazane z forum i np. 5 roznych grup modow, ktorym sie nada np. full role ale tylko do 1 kawalka forum - kazdej grupie do innego. no i dalej przydzielamy userow do odp. grup. i mamy adminow, modow jak i modow ktorzy moga dzialac np. na 3/5 forum.

Ten post edytował halfik 8.12.2005, 03:58:45

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ą.

hmmm a w jakis sposob chcesz parametryzowac te grupy?
no zalozmy ze mamy ta grupe modow i 10 forum o id 1-10. i teraz chodzi mi o baze - chcesz wprowadzic jakas tabele opisujaca role grup czy co tam?

obajanis mi prosze ta koncepcje ale nie w obrebie ze mamy forum, ale w obrebie calego jakiegos tam systemu.

Wygląda to tak:

Mamy akcję, która manipuluje danymi. Chcemy mieć kilka różnych zestawów danych, które będą istniały niezależnie od siebie. Musimy jakoś identyfikować te zestawy - intuicyjnie będziemy je oznaczać liczbami naturalnymi. W momencie wywołania akcji musi być znany identyfikator zestawu. Przed wywołaniem akcji musimy do naszego kontrolera (za kontroler przyjmiemy system autoryzacji) przekazać:
- Nazwę akcji
- Parametry z jakimi ją wywołujemy
- Specyfikację dostępu (czyli grupy, role i ich parametry)

Następnie musimy mieć dostęp do obiektu użytkownika, który będzie zawierał informację o rolach i grupach oraz ich parametrach. Teraz możemy wszystko porównać.

Przykład:
Użytkownik posiada rolę doAction, do której musimy przekazać parametry - domyślnie nie ma żadnego. Podajemy numer zestawu - powiedzmy, że 1. Akcję więc opisujemy następująco: doAction(1). Co z grupami? Podając parametry dla grupy możemy je jednakowo przekazać wszystkim rolom (jeżeli nasza hierarchia wygląda tak jak u Halfika).

Akcja wymaga roli doAction. Możemy wydzielić trzy metody postępowania z parametrami:
1. Parametry są opcjonalne (to raczej tylko dla wstecznej zgodności...).
2. Parametry są wymagane - jeżeli nie ma żadnego, to rola nie ma sensu.
3. Nie ma parametrów.

Teraz przechodzimy do meritum sprawy Kontroler otrzymuje żądanie autoryzacji tego użytkownika dla tej akcji oraz podaje parametry z jakimi ma zostać wywołana akcja. Używamy zestawu pierwszego, więc interesującym nas parametrem będzie "id", którego wartość będzie równa 1. Konfiguracja akcji wymaga posiadania roli doAction oraz parametru. Jak zatem powiedzieć kontrolerowi o co nam chodzi? Musimy w jakiś sposób przekazać mu informację o tym, że musimy znaleźć na liście parametrów roli konkretny parametr akcji. Zapiszmy to tak:



Teraz cały proces autoryzacji będzie wyglądał następująco:
1. Szukamy akcji doAction.
2. Pobieramy parametr id z żądania (posiada wartość 1).
3. Porównujemy listę parametrów roli (która w tym przypadku jest jednoelementowa, a jej jedyny element ma wartość 1).

Jeżeli znajdziemy parametr na liście, to zezwalamy na wywołanie akcji. W przeciwnym wypadku zmieniamy ścieżkę wykonania programu.

Tak to mniej więcej wygląda.

Uwagi:
- Kolejność parametrów jest ignorowana, szukamy tylko wspólnych elementów.
- Parametr może być dowolną wartością skalarną.
- Jeżeli chcemy wprowadzić dostęp do wszystkich zestawów, możemy przypisać roli użytkownika jeden parametr "*".
- Podział odpowiedzialności akcji musi być odpowiedni, aby nie pomieszać parametrów. Lepiej pomyśleć chwilę nad konstrukcją akcji niż mieszać przy konstrukcji parametrów.
- Jeżeli wywołamy akcję z fikcyjnym zestawem np. 13, wtedy użytkownik nie otrzyma uprawnień i może zostać wyrzucony błąd autoryzacji. To jest nieprawda, gdyż użytkownik nie ma prawa mieć dostępu do czegoś, co nie istnieje. Wypada sprawdzić wcześniej czy faktycznie ten zestaw istnieje.

Zapis parametrów w bazie jest luźny - lekko zmieniamy formę, w której zapisywaliśmy role/grupy. Musimy tylko umieć skojarzyć identyfikator zestawu z parametrami ról.

Update:
Tak by wyglądał przykłądowy wpis do bazy:

Jeżeli grupa by wyglądała tak:

To użytkownik by posiadał ostatecznie role doAction(1,5,9), doOtherAction(3), doAnything(*), roleOne(1,3,7), roleTwo(1,3,7). To jest tylko przykładowy zapis.

Mam nadzieję, że jest w miarę jasno i nie zapomniałem o niczym.

Ten post edytował Ludvik 8.12.2005, 22:03:53

no dobra, a skad kontroler ma wiedziec jakie sa mozliwe parametry dla danej akcji? wklepywac to na stale w kod to raczej srednio ciekawy pomysl. czyli trzeba pocisnac na baze i opisac role mozliwymi parametrami. tak to chcesz zrobic?

widze ze tak

ale w tym momencie dodawanie rol staje sie ciut bardziej klopotliwe. bo jak pisac taki system dla kogos kto nie jest koderem, a ma to tylko adminowac, to ebdzie trzeba mu jakos umozliwisc dodawanie parametrow do roli. czyli mamy ciut wiecej roboty. ale czy warto hmm...?

wydaje mi sie ze tak, ale musialbym cos takiego napisac zeby zobaczyc o ile wiecej roboty przy tym i czy wiecej czasu w to wlozonego da wieksze mozliwosci bez utraty elastycznosci.

jak juz to zaimplementujsz daj znac jak rozwiazanie sie sprawdza

Ten post edytował halfik 9.12.2005, 11:44:45

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

Zmieniamy na taki kod


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.

hehe, to jak kiedys juz to napiszesz walnij na forum "odczucia" juz po. mysle ze w trakcie implementacji dojdziesz do jakis ciekawych wnioskow.

ta sesja idzie hehe. ale Cie pociesze - ja do lutego musze oddac prace dyplomowa




nom bedzie troszke zabawy zeby to bylo user friendly ("milusie" dla usera ). ale problemu tez nie widze.


eeee a gdzie ja pisalem o jakiejs specjalnej grupie? grupy przeciez sa na bazie i admin z poziomu jakiegos tam panelu moze je sobie dodawac, usuwac, edycowac i ogolnie czarowac na nich.


do czego sie odnosisz z tymi wyjatkami?


mi nie chodzi o wersje czegokolwiek. ciekawi mnie na jakie problemy sie natkniesz podczas implementacji, ich rozwiazania i ogolnie wnioski koncowe. pewnie kiedys bede jeszcze potrzebowal napisac cos podobnego, a wiedzy nigdy za duzo.

Ten post edytował halfik 10.12.2005, 01:15:39

Nie chodzi o to, że grupy są specjalne, ale trzeba je traktować specjalnie. Bo jak miałbyś zamiar zasygnalizować, że użytkownik jest właśnie autorem newsa? Sam się zastanawiam jak to zrobić u siebie, żeby nie trzeba było mieszać w kodzie. U mnie akcje nie mają dostępu do kontrolera dostępu i tutaj pojawia się problem - jak sprawdzić te sytuacje wyjątkowe? Ostatecznie można sprawdzić prostym wyrażeniem warunkowym już w akcji, ale nie podoba mi się to. Moje rozwiązanie polegało by na wprowadzeniu małych obiektów przypisywanych konkretnym akcjom, w których moglibyśmy sprawdzać rzeczy zależne od konkretnych akcji. Użytkownik wciąż by nie miał bezpośredniego dostępu do samej akcji. Jak wy ten problem widzicie?