kontrola dostepu Opcje

[Ace]

małe obiekciki - najprosciej by bylo potraktowac je jako grupy...

masz odczyt na grupe news i mozliwosc tworzenia
kazdy nowo utworzony news tworzy tez grupe news_ID i dziedziczy on uprawnienia z news + masz dostep do usuniencia, edycji.

Jak chcesz komus jeszcze dac dostep do obiektu to przypisujesz go do tej grupy news_ID

Czytam sobei co jakis czas wasze przemyslenia, i sadze ze tez powinienem zabrac sie za projekt wlasnego systemu uprawnien, ale napewno bedzie sie opieral na grupach/rolach. Tworzymy grupe, dodajemy do niej role, czyli grupa ma jakies mozliwosci i wrzucamy usera w grupe. Uprawnienia sie sumuja z wszystkich grup.

Zastanawia mnie wydajnosc, gdyz chce poprac sobie liste ostatnich 30 newsow, (ostatnie newsy nie tylko te do ktorych ma mdostep) i chce zeby przy moich newsach byla ikonka edycja, a przy pozostalych nie. Jak to rozwiazuje? Zapytanie do bazy o 30 ostatnich newsow, a pozniej w petli sprawdzam jeszcze uprawnienia do pojedycnzego obiektu, czy moze juz podczas pobierania obiektu zapytanie jest skonstruowane w taki sposob zeby pobieral moje uprawnienia do tego obiektu?

Pozdrawiam.

[Ludvik]

Rzecz w tym, aby nie tworzyć niepotrzebnych grup, bo potem nie opanujesz tego. Zobaczymy jak sprawdzi się mój pomysł. Jako że w szkole dużo się dzieje, szukam czasu, żeby coś z kompem zrobić, to na pisanie prawie nie zostaje nic... Ale postaram się.

Ace: Co do twojego problemu. To jest takie trudne ani wolne.

Zgodnie z moim pomysłem wyglądało by to tak: Najpierw standardowo musimy mieć dostęp do ról i parametrów. Potem obiekt pomocniczy zajął by się szukaniem uprawnień związanych z edycją newsów, czyli po prostu roli editNews. Do wywołania akcji dodaje wszystkie parametry tej roli. Powiedzmy, że mamy trzy parametry: OWN, 3, 5. Pierwszy to stała oznaczająca możliwość edycji swoich newsów, a dwie kolejne to po prostu identyfikatory pozostałych zestawów, w których znajdują się newsy objęte możliwością edycji. Wywołujesz akcję i wykonujesz szybkie sprawdzenie dla każdego newsa po kolei:

1. Czy id użytkownika jest takie samo jak autora? Tak - dodajesz możliwość edycji. Nie - następny punkt...
2. Czy id zestawu newsa znajduje się pośród parametrów roli editNews (przekazaliśmy je jako parametr do akcji)? Tak - dodajesz możliwość edycji. Nie - nie ma możliwości zmian.

Zauważ, że nie wykonujesz ani jednego dodatkowego zapytania, a sprawdzanie jest bardzo szybkie.

[Ociu]

Myślę, że można zrobić tak:
Groups

Kod

| id |  name |         read         |        write        | delete |
| 1  | maker | news, articles, etc. | news, articles etc. |  null  |

Gdzie w write wchodzi także edytowanie.

Members

Kod

| id | Group_id | Username |
|  1 |    1     |   ociu   |

[PHP] pobierz, plaintext 
<?php
final class GroupAuthorize {
public $group = array();
 
public function __construct( DataBase $db ) {
$w = $db->execute('SELECT * FROM Groups');
while($r = $w->next() {
$this->group[$r['name']]['read'] = ($r['read'] == null) ? false : $r['read'];
$this->group[$r['name']]['write'] = ($r['write'] == null) ? false : $r['write'];
$this->group[$r['name']]['delete'] = ($r['delete'] == null) ? false : $r['delete'];
} 
}
}
?>
[PHP] pobierz, plaintext 

Co wy na to ?
pozdrawiam

[Ludvik]

A jak ktoś zechce dodać możliwośc przenoszenia? Można dużo rzeczy wymyślić... Ja bym nie wiązał się za bardzo ze strukturą bazy danych, chyba że masz system, który nie będzie wymagał późniejszych zmian. Tak jest z systemem plików, gdzie nie trzeba się męczyć, aby dokładnie opisać uprawnienia.

[halfik]

ta ta tabela z rolami jest to chrzanu.
wlasnie o to chodzi ze wszsytko ma byc elastyczne. wchodzi admin, dodaje nowa role i to ma dzialac. wywala role i ma dzialac. itd.

[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

[Ludvik]

Hmmm... trochę niejasny ten opis dla mnie, przynajmniej nie rozumiem dlaczego ograniczasz się tylko do trzech akcji(?). A jak by wyglądało u ciebie rozwiązanie dwóch podstawowych problemów - edycji tylko własnych newsów oraz moderacji forum?

Poza tym nie wszystko na tym świecie da się opisać w trzech słowach - dodaj, usuń, edytuj, a tak odbieram właśnie twoje rozwiązanie. Co z wyświetlaniem? Co zrobisz w sytuacji, kiedy użytkownik ma mieć dostęp tylko do części obiektu? Możliwośc edycji ma, ale nie do końca. Właśnie w takich dziwnych sytuacjach role wydają się być przyjaźniejszym narzędziem.

Jeżeli Cię źle zrozumiałem, to wyjaśnij to trochę dokładniej z przykładami.

[splatch]

uprawnienia ograniczone do read, write, delete to pomyłka. Pomyłka dlatego, że chcemy dać możliwość zmieniania autorowi treści którą wprowadził do systemu, ale chcemy zablokować możliwość zmiany kategorii. W takim układzie musimy użytkownikowi przydzielić i tak uprawnienia do zapisu. Moim zdaniem najlepszym wyjściem jest przydzielanie praw do konkretnej, nazwanej akcji.

[sobstel]

Moim zdaniem najlepszym wyjściem jest przydzielanie praw do konkretnej, nazwanej akcji.

tez tak uwazam, jednak widze jeden problem. np. system newsow, ktos moze dodawac newsy, ale edytowac moglby tylko swoje newsy (te ktore sam dodal) - wtedy nie mozna dac mu praw news_edit bo bedzie mogl wszystkie edytowac. na razie nie mam pomyslu jak to rozwiazac, poza wprowadzeniem jakichs parametrow - np. przydzielamy uprawnienia news_edit z parametrem only_own, parametr przekazywany do akcji i akcja wie jak sie zachowac, ale nie jest to rozwiazanie idealne dla mnie i troche komplikuje sprawe.

[NuLL]

ta ta tabela z rolami jest to chrzanu.
wlasnie o to chodzi ze wszsytko ma byc elastyczne. wchodzi admin, dodaje nowa role i to ma dzialac. wywala role i ma dzialac. itd.

Uzyskanie czegos takiego jest wg mnie niemozliwe. Jesli jest chcialbym zobaczyc dzialajacy przyklad a nie slowa - implementujmy to co jest mozliwe do napisania a nie rzeczy z kosmosu.

Ja tabele z rolami mam ale u mnie to wyglada inaczej. W danych usera jest lista uprawnien jakie on posiada. Uprawnienia sa jako idki uprawnien w tabeli roles i tyle. Calosc systemu mozna zmienic aby konkretna role pobieral tylko wtedy kiedy ja trzeba sprawdzic. Pozatym mam klase accessParameter w ktorej moga sobie zdefiniowac nazwe zmiennej oraz jej zakres dla danego usera - i w ten sposob user moze edytowac newsy w konkrentej kategorii. Ja mam w systemie tez podstawowe akcje jak to sie jest prosto nazywa CRUD (create, read, update ,delete) plus akcje do obiektow wlasnego autorstwa. Reszta chodzi dzieki temu co jest wyzej.

[bela]

Ja tam wiem jak to rozwiązać (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg)
Mamy sobie globalny filtr, który sprawdza role dla akcji - ok, ale to czasem nie wystarcza. Co wtedy? Dodajemy drugi filtr pod konkretną akcje, który to sprawdza czy user może mieć dostęp np. do danej kategorii.

Może trochę na około, ale chyba najlepsze rozwiązanie.

[Ludvik]

ta ta tabela z rolami jest to chrzanu.
wlasnie o to chodzi ze wszsytko ma byc elastyczne. wchodzi admin, dodaje nowa role i to ma dzialac. wywala role i ma dzialac. itd.

Uzyskanie czegos takiego jest wg mnie niemozliwe. Jesli jest chcialbym zobaczyc dzialajacy przyklad a nie slowa - implementujmy to co jest mozliwe do napisania a nie rzeczy z kosmosu.

A dlaczego miało by to być niemożliwe? Od tego mamy bazę, przejrzystą jej budowę i składnię, którą stosujemy do opisu ról, aby można było łatwo operować na danych. Role mamy od tego, żeby nie mieszać w kodzie aby opisać wymagania do uzyskania dostępu. Grupy po to, aby nie nadpisywać ról każdego użytkownika po kolei. Szkoda, że nie mogę ci przedstawić żadnego kodu, bo czas mi na to nie pozwala, ale pracuję nad tym. Można na święta coś będzie gotowe.

Sopel: Ten przypadek jest o tyle nieciekawy, że trzeba porównać w jakiś sposób id użytkownika i identyfikator autora newsa. Ja swój pomysł opisywałem na poprzedniej stronie tematu i wydaje mi się, że jest to najprostsza metoda wybrnięcia z problemu. Obiekty pomocnicze nie stanowią ani problemu wydajności, ani wzrostu złożoności aplikacji. W twoim rozwiązaniu musimy dopuścić użytkownika do akcji, nawet jeśli nie ma prawa do jej wykonania - przecież musimy jakoś sprawdzić czy jest autorem. U mnie tym zajmuje się ten obiekt pomocniczy (dla wygody można go nazwać ActionPrefetcher czy coś w tym stylu). Wczytujemy newsa, sprawdzamy wszystko co trzeba, a samą wiadomość zapisujesz gdzieś. Wychodzę z założenia, że największym złem jest dopuszczanie akcji do zabawy w uprawnienia. Właśnie to rozwiązanie wraz z rolami parametryzowanymi pozwala mi na osiągnięcie tego celu. Dokładniejszy opis jak mówiłem - trochę wcześniej w temacie.

Bela666: Jesteś najbliżej mojego pomysłu, chociaż sam przyznałeś, że to trochę na około. Różnica polega na tym, że ty masz filtr, który sprawdza specjalne uprawnienia. Ja pozostawiam sprawdzanie uprawnień głównemu filtrowi autoryzującemu, ale daję możliwość nadania użytkownikowi specjalnych ról/parametrów przed nadaniem prawa dostępu. Poza tym mój obiekt będzie trochę lżejszy (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)

Ten post edytował Ludvik 19.12.2005, 17:25:06

[sobstel]

hmmm, przyznam ze do konca nie przemawia do mnie, a raczej nie do onca rozumiem idee tych obiekcikow jakby to mialo dzialac. ja bardziej myslalem juz np. o umieszczeniu w kazdej akcji metody (moze nawwet statycznej, zeby nie wywolywac akcji) access do ktorej przekazywane by byly odpowiednie argumenty i ona by zwracala true lub false.

[Ludvik]

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

[bela]

Bela666: Jesteś najbliżej mojego pomysłu, chociaż sam przyznałeś, że to trochę na około. Różnica polega na tym, że ty masz filtr, który sprawdza specjalne uprawnienia. Ja pozostawiam sprawdzanie uprawnień głównemu filtrowi autoryzującemu, ale daję możliwość nadania użytkownikowi specjalnych ról/parametrów przed nadaniem prawa dostępu. Poza tym mój obiekt będzie trochę lżejszy (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)

Nie sądzę, filtr sprawdzający role to góra 20 linijek. Długość drugiego jest uwarunkowana stopniem złożoności schematu autoryzacji.

[Ludvik]

Z tą różnicą, że znowu musisz się bawić w porównania, a ja to robię tylko raz. Pomijając fakt, że filtr autoryzujący tak czy innaczej już istnieje. Trudno dyskutować bez przykładów czy schematów, a ja mi niestety czas nie pozwala, aby zrobić to w jeden-dwa dni :/ Więc jak będę już coś miał zrobione to opiszę to tutaj.

[eai]

Ja rozwiązałem całość w ten sposób.

tabela groups

Kod

group_id | group_name | group_permission | group_description

tabela user_groups

Kod

id | user_id | group_id

pole group_permission to zserializowana tablica z prawami dostępu. Jeśli klucz nie istnieje w tablicy oznacza to brak dostepu.
Kazdy user moze nalezec do kazdej grupy (jego prawa dostepu lacza sie w jedna tablice)

Zmiana uprawnien to operacje na tablicy wiec jest latwosc wprowadzania zmian, usuwania itd.
Mozna latwo napisac zapytanie przenoszenia userow z jednej grupy do drugiej itp (oczywiscie odpowiednie zapytanie, zeby usuwac tych co juz sa w danej grupie)

Dla mnie rozwiazanie jest proste i daje duzo mozliwosci.