ugrás a tartalomhoz

Összetett jogosultság-kezelés például Unixhoz hasonlóan?

mocsar · 2006. Május. 23. (K), 20.00
Van egy remek cikk a weblaborban a cikkek között a php rovatban: Cikkek > PHP > Jogosultság kezelés. Cikksorozatnak indult, de sajnos az utolsó rész nem jelent meg.

A fórum keretein belül szeretném a szakértőket rávenni, hogy világosítsák meg a következő témát:

„...szeretnénk, ha minden felhasználó csak az általa létrehozott cikkeket tudná szerkeszteni. Egy ilyen esetben a jogosultságot egy függvényként foghatjuk fel, mely az aktuális paraméterek (cikk, felhasználó azonosító) birtokában képes eldönteni, hogy a felhasználó a kívánt funkció elérésére ténylegesen jogosult-e vagy sem. Ezeket hívtam a bevezetőben összetett jogosultságoknak...”


A fenti feladatot hogyan oldanátok meg? A táblákban létrehoznátok egy mezőt, ami a jogosultságokról tartalmaz információt? Pld. a Unixhoz hasonlóan: -rw-------.
Hogyan lehet ebben az esetben szabályozni az új sorok létrehozását? Kell valami mechanizmus, ami meghatározza, hogy egy adott felhasználó vagy csoport esetén milyen értékekkel tölthetőek fel az új sor mezői (pld. a más táblákba mutató mezők /foreign keys/).

Meg tudom oldani a feladatot úgy-ahogy, de egy olyan megoldás érdekel, ami a jövőben bővíthető.
‹ lekérdezés pontos egyezéssel (kis-nagybetűk tekintetében) Nem tudok kapcsolódni a MySql szerverhez ›
 ■
1

jogosultságok

Raziel Anarki · 2006. Május. 23. (K), 22.50
érdemben nincs időm hozzászólni, de szerintem érdemes megnézni postnuke és a drupal jogosulság kezelését

tudsz valami példát mondani erre foreign keyes dologra?
2

cms

mocsar · 2006. Május. 24. (Sze), 00.36
Igen-igen, valóban a cms rendszerek jogosultságkezelése a követendő példa, és valószínüleg az lesz a sorsom, hogy ki kell veséznem az egyiket. Ezt szeretném megúszni.

Foreign keys (külső kulcsok): például vannak témakörök, és vannak cikkek, amelyeket egy-egy táblában tárolunk. A cikkeket tartalmazó tábla egyik oszlopa (ebben vannak a külső kulcsok) mondja meg, hogy a cikkek mely témakörbe tartoznak. Egy-egy felhasználó nem szerkesztheti az összes cikket (az egész táblát), csak egy adott témakörbe tartozó cikkeket. Tehát csak azokhoz a sorokhoz (cikkekhez) lehet hozzáférése, amely sorok külső kulcsmezőjében az adott támakör azonosítója szerepel.
3

"dióhéjban"

Raziel Anarki · 2006. Május. 24. (Sze), 02.19
megoldhatod úgy pl, h a témakörökre is és azon belül a témákra is külön-külön megadsz pl view/add/edit/delete jogosulságokat, és amikor valaki megnézni/létrehozni/szerkeszteni/törölni akar, akkor megnézed h az adott témakör/cikk párra mi a jogosulsága. (létrehozásnál csak témakörre)

pl egy ilyen táblával (postnuke szerűen)
table perms:
   int id primary
   int order
   int userid      //vagy groupid
   int catid
   int articleid
   enum accesslevel: view, add, edit, delete
userid, catid, articleid nél mondjuk -1 jelenti az "összest"

userid(groupid) -nél meg lehet még 0 a "regisztrálatlan"

pl:
(order, userid, catid, articleid, acceslevel)

1, -1, -1, -1, view   //mindenki olvashat mindent
2, 1, -1,  -1, delete //az 1es felhasználónak minden joga megvan mindenhova
3, 2,  1,  -1, edit   //2es felh, az 1es katban létrehozhat+szerkeszthet
4, 2,  1,   1, view   //kivéve az 1es cikket mert azt csak nézheti
a 4es orderjű jogosultság felülbírálja a 3ast ami az összes cikkre vonatkozik, mert order szerint később van.

orderre azért van szükség, hogy amikor új jogosultságot illesztesz a táblába, meg tudd határozni milyen sorrenben találja meg az ellenőrző függvény.

a postnuke jogosulságkezelése is kb erről szól, csak ott az elemet amire a jogosulság vonatkozik regexp-el adja meg a tábla, és modulonként. a modulok pedig saját séma szerint nézik a kulcsokat

pl cikkeknél a séma "kategória:cikkid"
pl "2:1" az adott cikkre, és ilyen jogok vannak h ".*", "2:.*" (összes, 2es kat összes)
vagy szavazásnál a sáma "szavazásid:", pl "3:" az adott szavazásra

a drupaléba még nem ástam bele ennyire magam, de ott azt hiszem megadott lehetőségek (x modul definál y jogot pl: "kommentek/új komment", vagy "keresés/keresés az oldalon" és arra lehet "igen/nem" az engedély felhasználói csoportonként)

na de most már alszom :D
4

danke

mocsar · 2006. Május. 24. (Sze), 13.41
Köszönöm szépen, mégiscsak érdemben szóltál hozzá...
Ezen a nyomon el tudok indulni.
5

tesztkérdés

mocsar · 2006. Május. 24. (Sze), 15.44
Utolsó két kérdés, hogy jól értem-e:

1. Tehát ha a postnuke módszerét követem, akkor az általad megadott kód valahogy így módosul: 
CREATE TABLE perms (
  id int,
  order int,
  userid int,
  item_id_string varchar(255),
  accesslevel enum ('view', 'add', 'edit', 'delete'),
  PRIMARY KEY  (`id`)
) ;
ahol az item_id_string tartalmazza az elemet meghatározó kifejezést, pld. "2:1".

2. „...az elemet amire a jogosulság vonatkozik regexp-el adja meg a tábla, és modulonként.”
Pontosan mit jelent az, hogy „modulonként”? Modulonként más módon?
6

.

Raziel Anarki · 2006. Május. 24. (Sze), 16.29
1.

én valami ehhez hasonlót csinálok (mysql):
SELECT `accesslevel`
FROM `perms`
WHERE `userid` IN ('-1', $user_id)   //0: nem regisztrált
   AND ('$item' REGEXP `item_id_string`)
ORDER BY `order`
LIMIT 1";

az $itemben "2:" van ha kategóriát nézel, "2:1" ha cikket, és ":" ha általánosan

az adatbázisban pedig a regexpes stringek: ".*", "2:.*" "2:1"

megj: az előbb fordítva írtam a pédában a 3as és 4es jogot, értelemszerűen amelyiket előrébb rakod, azt fogja hamarabb megtalálni ez a lekérdezés

2

a postnuke-ben van még egy varchar a táblában ami a 'komponens'-re vonatkozik, abban van a modul neve és az is regexpes, pl regisztrált felhasználóknak [module:.*, .*, comment] a joguk, de a [module:admin, .*, none]

vagy a blokkoknak "block:<block_title>" alapján (pl adminmessages blokk lehet így elrejtve a felhasználók elől)

(ott 'none', 'overview', 'read', 'comment', 'moderate', 'add', 'edit', 'delete' és 'admin' jogok vannak 0-tól 8-ig számozva)
7

regexp

Anonymous · 2006. Május. 27. (Szo), 14.16
A regexp-es kifejezések elejére nem kell egy ^ jel?
A fenti példák nekem így működnek "^2:1", "^2:.*" és "^3:".
8

phpgacl

Hodicska Gergely · 2006. Május. 28. (V), 16.40
Van egy ilyen projekt is, ami pont ilyenfajta jogosultság kezelés megvalósítására lenne hivatott. Konkrét tapasztalatom nincs vele, de állítólag egész jó.


Felhő