Organizacja danych przechowujących uprawnienia użytkowników, Projekt tabeli na potrzebę przechowywania praw użytkowników CMSa Opcje

[Daiquiri]

Witam,

Jestem w trakcie pisania CMSa, w którym ma znajdować się szerokie zróżnicowanie praw jakie posiadać będą użytkownicy. Administrator będzie miał możliwość nadawania bardzo szczegółowych "przywilejów", dla przykładu skrócona lista:

• możliwość dodawania treści na stronę
• możliwość edycji istniejącej treści
• możliwość usuwania istniejących treści
• wgląd w logi
• zarządzanie reklamą
• zarządzanie użytkownikami administracyjnymi
• zarządzanie użytkownikami serwisu
• zarządzanie kategoriami treści

Nie ma więc możliwości stworzenia domyślnych rang typu redaktor, moderator itd. Rozwiązanie (znane np. z Drupala) polegające na tworzeniu dowolnej rangi z konkretnymi przywilejami, a później przydzielanie jej użytkownikowi nie wchodzi w rachubę (ze względu na zlecającego). Całość ma wyglądać w następujący sposób: administrator startuje z tworzeniem nowego użytkownika (bądź edytuje istniejącego), podaje jego dane (nazwę, maila i tym podobne) i w tym miejscu ma listę praw (coś na kształt tej powyżej), zaznacza część z nich (wedle uznania) i tworzy użytkownika z konkretnymi przywilejami.

Zastanawiam się jednakże jak takie informacje przechowywać w bazie... być może zmęczenie materiału nie pozwala mi już "trzeźwo" myśleć (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) . Rozważałam stworzenie tabeli z prawami do której przypisywany będzie użytkownik. Przykładowo kolumna opisana jako dodawanie treści na stronę a w wierszach klucze identyfikujące użytkowników. Nie mam jednak pewności co do tego na ile optymalne jest to rozwiązanie.

Być może ktoś już projektował podobne rozwiązanie i ma jakiś pomysł?

[blooregard]

Ja rozwiązałem podobny problem następująco (w uproszczeniu):
Mam tabele 'perms', gdzie każdy rekord to ID uprawnienia i jego opis. Z kolei każda akcja w CMS-ie ma przyporządkowany ID konkretnego uprawnienia.
Druga tabela 'perm_to_user' łączy już konkretne uprawnienia z konkretnymi userami (jeden rekodr to relacja ID uprawnienia->ID usera).

W dodawaniu/edycji użytkownika mam formularz: checkbox+opis (zanzacenie checkboxa oznacza nadanie uprawnienia).

W konkretnej akcji jest f-cja checkPerm($perm_id, $user_id), która sprawdza, czy w tabeli 'perm_to_user' występuje rekodr zawierający ID uprawnienia oraz ID zalogowanego uzytkownika - jeśli tak, znaczy to, że dany użytkownik ma nadane prawa do tego modułu czy tam akcji. Jesli nie - żegnaj, Gienia.

[progresmedia]

Ja bym to zrobił na jeden z dwóch sposobów:
- oddzielna tabela z rangami, czyli kolumna user_id i kolumna function, i później możesz selectem w prosty sposób sprawdzić kto co może
- kolumna w tabeli użytkowników pt. "prawa" i w niej ciąg funkcji które użytkownik może wykonywać, np. "edycja/usuwanie" i później również za pomocą SELECT (..) LIKE (..) możesz sprawdzić kto co może (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)

[omeck]

Ja bym to zrobił na jeden z dwóch sposobów:
- oddzielna tabela z rangami, czyli kolumna user_id i kolumna function, i później możesz selectem w prosty sposób sprawdzić kto co może

Autor postu chyba nie może rozdzielić na rangi.

Szkoda, że nie możesz zrobić ACL z prawdziwego zdarzenia :-/ Czy nie najprościej i najszybciej byloby trzymać uprawnienia np. w pliczku ini:

Kod

[perms]
user1 = zasob1 zasob2 zasob3
user2 = zasob2 zasob4

Czyli definiować role (u Ciebie chyba nie może być rol, wiec tutaj trafialiby wszyscy uzytkownicy - niefajne) i przypisywać im identyfikatory zasobów.

Plusem jest na pewno to, że nie trzeba na poziomie bazy przy każdym request'ście sprawdzać uprawnień, a czytac z pliku (parse_ini_file" title="Zobacz w manualu PHP" target="_manual).

Ten post edytował omeck 7.07.2009, 19:23:15

[Daiquiri]

Najchętniej wykorzystałabym mechanizm budowania przez administratora rang z dowolnymi przywilejami... no ale nasz klient nasz pan.

Trzymanie wszystkiego w tabelach i odczytywanie poziomu dostępu "na życzenie" danego modułu jest dla mnie trochę słabe, ale z drugiej strony jak inaczej to przechowywać? Chyba zdecyduje się na trzymanie tego w tabeli z perms'ami (jak sugerował blooregard) z tym, że wczytam je jako zmienne sesji dla każdego użytkownika. Wtedy zapytanie wykona się raz, a konkretne funkcje odwołają się z pytaniem o pozwolenie do wartości tej zmiennej.

omeck - zastanawiałam się nad plikiem, ale sama nie wiem... myślę, że zmienne sesji załatwia mi problem wiecznych requestów do bazy (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) .

Dziękuję za podpowiedzi!

[witul]

A ja mam taki sposob. Mam tabelke przechowujaca wszystkie akcje systemu w postaci id=>link, np.
1=>'/administrator/article/editform',
2=>'/administrator/article/editsubmit'

Kazda publiczna metoda kontrolerów to akcja wpisana w ten sposob do tabelki.
Druga tabelka przechowuje nazwy operacji - dodawanie artykułów, edycja artykułów, usuwanie etc.
3 tabelka wiaze akcje z "operacja", przez co system wie ze ze edycja artykulow to akcje: /administrator/article/editform, /administrator/article/editsubmit.
Teraz mozemy przyznac userowi czy grupie userow uprawnienie nie do wykonywania konkretnych metod ale calych operacji, np edycji artykułów
Schematycznie tak to wygląda i nawet sie sprawdza.
Do tego widok w postaci tabelki z checkboxami przyznajace grupie uprawnienie do edycji artykulow

Uprawnienie sprawdza konstruktor klasy rodzica w kontrolerze
Wygodne i czytelne (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)

Ten post edytował witul 11.07.2009, 03:10:08

[AxZx]

rozwiązanie z pluginu sfguarduser do symfony:

[SQL] pobierz, plaintext 
CREATE TABLE `sf_guard_group` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `name` varchar(255) NOT NULL,
  `description` text,
  PRIMARY KEY  (`id`),
  UNIQUE KEY `sf_guard_group_U_1` (`name`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;
 
CREATE TABLE `sf_guard_group_permission` (
  `group_id` int(11) NOT NULL,
  `permission_id` int(11) NOT NULL,
  PRIMARY KEY  (`group_id`,`permission_id`),
  KEY `sf_guard_group_permission_FI_2` (`permission_id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;
 
CREATE TABLE  `sf_guard_permission` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `name` varchar(255) NOT NULL,
  `description` text,
  PRIMARY KEY  (`id`),
  UNIQUE KEY `sf_guard_permission_U_1` (`name`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;
 
CREATE TABLE `sf_guard_user` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `username` varchar(128) NOT NULL,
  `algorithm` varchar(128) NOT NULL DEFAULT 'sha1',
  `salt` varchar(128) NOT NULL,
  `password` varchar(128) NOT NULL,
  `created_at` datetime DEFAULT NULL,
  `last_login` datetime DEFAULT NULL,
  `is_active` tinyint(4) NOT NULL DEFAULT '1',
  `is_super_admin` tinyint(4) NOT NULL DEFAULT '0',
  PRIMARY KEY  (`id`),
  UNIQUE KEY `sf_guard_user_U_1` (`username`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;
 
CREATE TABLE `sf_guard_user_group` (
  `user_id` int(11) NOT NULL,
  `group_id` int(11) NOT NULL,
  PRIMARY KEY  (`user_id`,`group_id`),
  KEY `sf_guard_user_group_FI_2` (`group_id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;
 
CREATE TABLE `sf_guard_user_permission` (
  `user_id` int(11) NOT NULL,
  `permission_id` int(11) NOT NULL,
  PRIMARY KEY  (`user_id`,`permission_id`),
  KEY `sf_guard_user_permission_FI_2` (`permission_id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;
[SQL] pobierz, plaintext 

możesz przypisywać użytkowników do grup, a grupom nadawać uprawnienia. możesz również przypisać uprawnienie poszczególnym użytkownikom.
wg mnie to jest rozsądne i dobre rozwiązanie. nic dodać nic ująć:)

Ten post edytował AxZx 11.07.2009, 09:23:59