Rozwiązania dot. grup użytkowników Opcje

[acztery]

Chciałem zapytać jakie rozwiązania stosujecie w klasa użytkowników ( dokładniej grupy użytkowników, uprawnienia itp ) Chodzi mi o jaknajbardziej logiczne i funkcjonalne rozwiązania.

Ja mam taki pomysł

Mamy np tabele group ( Id;Name;Desc;Priorytet ) i naprzykład 1 rekord 1;Admin;Administrator serwisu;0
i w tabeli user pole group i tam 0 albo no ( 4;5;2 ) i to by oznaczało ze operator forum, nowosci i moze edytowac wiadomosci ) nie wiem czy to logiczne. Tworze to do cms. chcial bym to tak zrobic ze w łatwy sposón można ustalać co kto może bez ingernecji w kod.

[Dandelion]

http://forum.php.pl/index.php?showtopic=38293&st=0

[AxZx]

link ktory podales prowadzi to tematu w ktorym sa jakies przemyslenia, teoretyzowanie.
malo konkretow.

zabralem sie za dostep do poszczegolnych akcji ale kilka niejasnosci mam nadal

np jest jakas akcja - edycja artykulu.
zwykly user moze go edytowac normalnie, ale admin moze cos wiecej, np przy edycji ma dodatkowe pole.

maja byc wtedy 2 osobne akcje? zalozmy ze roznilyby sie tylko 1 linijka kodu.

drugi problem to zapis uprawnien dla takiej sytuacji: user ma mozliwosc edycji artykulu ale tylko swojego.
jak to zapisac?
chcialem uprawnienia dla akcji zapisywac w pliku konfiguracyjnym.

pozdrawiam

[cadavre]

U mnie wygląda to następująco (wyciąg):
1. Tabela 'users':

Kod

id | login | groups | additional_rights

id, login - wiadomo
groups - nry grup oddzielone przecinkami
additional_rights - dodatkowe prawa dostępu
2. Tabela 'groups':

Kod

id | name | rights | hierarchy

id, name - wiadomo
rights - prawa dostępu
hierarchy - hierarchia grupy (admin = #1)

Ładowanie modułu u mnie wygląda następująco:

Kod

http://strona.pl/modul/funkcja/akcja

modul - załadowany moduł (np. newsy)
funkcja - (np. dodawanie newsa)
akcja - formularz / funkcja działająca na formie (tylko: form lub funct)

Right, czyli prawa wyglądają następująco:

Kod

modul/funkcja;modul/*;modul/funkcja_inna

Założyłem, że gdy usera ma dostęp do funkcji to ma naturalnie do wszystkich akcji również dostęp.
Prawa obsługiwane są przez reg_exp (stąd * jako wszystkie funkcje danego modułu). Prawa oddzielone są średnikami. Gdy user ma kilka grup - wszystkie prawa są odczytywane plus te z 'additional_rights' i duplikaty są usuwane. Następnie explode i preg_match. Główna grupa usera to ta najwyższa z hierarchii.

To tyle...

[AxZx]

rozumiem ze funckja to jest metoda klasy, a modul to jest wlasnie ta klasa?
funkcje dzielisz jeszcze na akcje czy jak?
jakie akcje sa w tej funkcji? co to sa akcje?

ja zrobilem podobnie tylko mam strona.pl/modul/metoda
czyli art/dodaj1

[Ociu]

http://forum.webcity.pl/index.php?showtopi...amp;#entry30569
http://forum.webcity.pl/rozwiazania-Uprawn...ikow-t2384.html

i wiele wątków na tym forum.

pozdrawiam

[cadavre]

Moduł: implementowana klasa
Funkcja: metoda klasy
Akcja: wyświetlenie formularza (np. z dodawanie newsa) lub druga: zapisanie tego newsa do np. bazy i wyświetlenie potwierdzenia.

[Turgon]

http://www.php.rk.edu.pl/w/p/cicms-prosty-...m-uzytkownikow/
Ja robię podobnie. Jest według mnie to ciekawie rozpisane.

[acztery]

a jednak do rozpoznawania przedziału praw dla danego usera wykorzystam przesuniecie bitowe. ale troszke inaczej jak ktos wczesnej juz to probowal robic. ale


cadavre mozesz mi poslac na mom21@tlen.pl paczke z tym zebym sobie zobaczyl jak to masz?

[cadavre]

@acztery - wyślij mi PM: dziś (znaczy do rana ) już na forum.php.pl nie będę wchodził to mi pokaże, że mam nową wiadomość. Jutro wyślę, bo dzisiaj już się mi szczerze nie chce.

Ten post edytował cadavre 30.12.2006, 01:19:31

[Speedy]

Wg mnie hierarchiczne uprawnienia użytkowników (np. mały administrator, duży administrator itd.), to zły pomysł. Czasem zachodzi potrzeba przydzielenia różnym użytkownikom bardzo zróżnicowanych uprawnień i wtedy taki system leży. Najlepiej utworzyć w tabeli użytkowników kolumny, które będą warunkowały uprawnienia - dla każdego modułu/elementu osobna kolumna. Ewentualnie można zrobić jedną kolumnę i trzymać w niej odpowiednią tablicę, albo ciąg liczb rozdzielonych jakimś separatorem, gdzie dana liczba odpowiada konkretnemu modułowi i jeśli jej w tym ciągu nie będzie, to użytkownik nie będzie miał uprawnień.
Krótko mówiąc, hierarchiczna struktura uprawnień jest nieelastyczna.

[cadavre]

W moim wypadku hierarchia nie ma znaczenia bo każda grupa może mieć przypisane dowolne uprawnienia. Oprócz tego user może mieć własne, dodatkowe uprawnienia. Planuję w niedalekiej przyszłości napisanie klasy do Access Control'a która aplikować będzie dwa rozwiązania - podstawowe prawa dostępu (każde) do modułu / funkcji oraz zaawansowane dot. szczegółowych praw tj. zapis/odczyt/modyfikacja/usuwanie...

[Athlan]

Popieram @Speedy. U mnie jest to zrobione tak, że każdemu użytkownikowi przypisuje sie pewne grupy podczas logowania. Za przechowywanie grup służy klasa User:

http://framework.vgroup.pl/expose-cab9852b...f33e1b4ac40.htm

Filtracja jest bardzo prosta. Jeżeli mamy grupy, możemy wykonac na nich różnorakie operacje, np jeżeli koleś ma grupę admin, moderator i banned to nie wejdzie w panel adminsitracyjny ze względu na tą trzecią. Jak zauważyliście podział grup jest na deny i allow. Grupy deny nie mają prawa dostępu do modułu (w moim przypadku konkretnej akcji kontrolera lub całego kontrolera), chociaż mają grupy uprawnione do jego przeglądania. Filtrem zajmuje się klasa ACL.Class.php

http://framework.vgroup.pl/expose-26bd1a93...f73da9723bf.htm

Zbieranie grup usera i przekazanie do klasy ACL to zadanie klasy Access:

http://framework.vgroup.pl/expose-f42de72a...51760e82bd4.htm

Całość dołącza się do FrontControllera. Przykladowa konfiguracja:

[PHP] pobierz, plaintext 
<?php
$aConfig['NewsAdmin_Vcontroller'] = array
(
 
	'edit_Action' => array
	(
		'access' => array
		(
			'allow' => array('admin', 'moderator'),
			'deny' => array('paused'),
		)
	)
)
?>
[PHP] pobierz, plaintext 

Grupa "paused" to tymczasowo zbanowani userzy, to Ci, którzy na przykład zalogowali się źle więcej niż 3 razy ale wkońcu im się udało.

Taki przyklad pozdrawiam, Athlan