Efektivní řešení uživatelských práv – MySQL – Fórum – Programujte.com
 x   TIP: Přetáhni ikonu na hlavní panel pro připnutí webu

Efektivní řešení uživatelských práv – MySQL – Fórum – Programujte.comEfektivní řešení uživatelských práv – MySQL – Fórum – Programujte.com

 

klinki0
Návštěvník
2. 2. 2008   #1
-
0
-

Zdravim mam takovej problem - nemuzu prijit na nejake efektivni reseni uzivatelskych prav :'(
Potrebuju abych mohl uzivatelum nastavit prava na:

1) a) zobrazeni uzivatelu
b) editaci uzivatelu
c) editaci opravneni u uzivatelu (zde bude zase omezeni ze uzivatel ktere bude mit opravneni odpovidajici moderatorovi nebude moct nastavovat moderatory a administratory ale napr. jenom redaktory a korektory atd..)
d) mazani uzivatelu
(zde jeste s omezenim na zobrazeni urcitych druhu uzivatelu - napr. nemuze zobrazit, smazat ani upravit uzivatele s nejvyssimi pravy atd..)

2) a) zobrazeni clanku v urcite kategorii
b) editaci clanku v urcite kategorii
c) pridavani clanku v urcite kategorii
d) editaci clanku v urcite kategorii

3) hlavni nastaveni webu


Rekneme ze budu mit tabulku uzivatelu:

uzivatele

id (INT) | jmeno (VARCHAR) | heslo (CHAR)
-----------------
1 | Pepa | (md5ka hesla)



Tabulka kategorii vypada takhle:
kategorie

id (INT) | nazev (VARCHAR) | url (VARCHAR) |
--------------------
1 | Hlavni | hlavni



Zatim me napadlo tohle reseni:

1) predelat tabulku uzivatele na tuto strukturu:
uzivatele

id (INT) | jmeno (VARCHAR) | heslo (CHAR) | (ENUM('superadmin', 'admin', 'moderator', 'korektor', 'redaktor', 'uzivatel')
--------------------------------------------------------------------------
1 | Pepa | md5 hesla | moderator



2) pro nastaveni prav na jednotlive kategorie toto:
uzivatel_kategorie

uzivatel_id (INT) | kategorie_id (INT) | opravneni (ENUM('zobrazeni', 'editace', 'mazani'))
--------------------------------------------------------------------------
1 | 1 | zobrazeni


3) pro config webu bude mit opravneni jen superadmin
4) pro udelovani vsech prav bude mit prava superadmin
pro udelovani prav nizsich nez je admin bude mit prava admin :-)
pro udeleni korektora a redaktora bude mit prava moderator


Akorat by me zajimalo jestli to nejde vyresit nejak efektivneji (urcite jde) a jak se vam zamlouva toto reseni? :)

Edit:
ted me napadlo jeste efektivnejsi reseni :)

tabulka opravneni - bude se tykat pouze opravneni na zobrazeni a editaci ostatnich uzivatelu

opravneni

id (INT) | nazev (VARCHAR)| priorita (tinyINT) | zobraz_prioritu (tinyINT) | edituj_prioritu (tinyINT)
1 | superadmin | 10 | 10 | 10
2 | admin | 9 | 8 | 8
3 | moderator | 7| 7 |
4 | kontrolor | 7 | 0 |


Priklad vyuziti:
Superadmin ma prioritu 10 (nejvyssi) a muze zobrazit a editovat vsechny uzivatele s prioritou 10 a niz
admin ma prioritu 9 a muze zobrazit a editovat jen uzivatele s prioritou mensi nez 9

Samozrejme by se dala ta priorita nastavit rovnou do tabulky uzivatelu... (bylo by to i rychlejsi atd..) ale musel by zde byt predpoklad, ze nebudou existovat 2 opravneni se stejnou prioritou

Nahlásit jako SPAM
IP: 85.13.98.–
survik1
~ Moderátor
0
Posthunter
2. 2. 2008   #2
-
0
-

tabulka uzeviatelu



nick | pass | special | spec_int
survik1 | dsds6dasd54asgdfh548er5 | superadmin | 1


při lognutí:


$_SESSION['spec_int'] = $query['spec_int'];


Ověřování:
if($_SESSION['spec_int'] < $query_somebody['spec_int'])

echo ' Na smazání tohoto uživatele nemáte dostatečné oprávnění';

Nahlásit jako SPAM
IP: 89.102.163.–
Život je jen hra, která se nedá vyhrát.
klinki0
Návštěvník
2. 2. 2008   #3
-
0
-

To survik1 : Tohle podle me neni zrovna dostacujici - nemas definovano zvlast co uzivatel smi editovat a co zobrazovat IMHO je lepsi to moje druhy reseni...
Ale dik za snahu :smile2:

Nahlásit jako SPAM
IP: 85.13.98.–
survik1
~ Moderátor
0
Posthunter
2. 2. 2008   #4
-
0
-

tak si vytvoř spec. přihl. tabulku pro adminy a tam si nastav enum hodnoty co smí a co nesmí ;)

Nahlásit jako SPAM
IP: 89.102.163.–
Život je jen hra, která se nedá vyhrát.
stepan0
Newbie
3. 2. 2008   #5
-
0
-

V jedné aplikaci jsme řešili s kolegou něco podobného. Výsledkem bylo API v podobě databázových procedur, které v parametru přijímaly identifikátor uživatele a při jednotlivých voláních docházelo k ověření, jestli má uživatel k proceduře/funkci přístup nebo ne. Velkou výhodou je, že odstíníte aplikační vrstvu od databázových tabulek a můžete provádět kontrolu práv v databázi.

Postup je následující:
1) Vytvoření procedur pro přístup k jednotlivým funkcím - např. založení (kolekce) záznamu, načtení záznamu, odeslání objednávky atd.
2) Tabulka, která obsahuje jméno procedury a roli, která k ní může přistupovat. Procedura, která bude ověřování proti tabulce vykonávat a bude volána ze všech procedur, které jsou součástí API.

Tento přístup má několik výhod: bezpečnost (odolnost vůči script injection, možnost autorizace na úrovni DCL), kontrola nad kódem (100% kontrola nad zpracovávnými daty), efektivní návrh (velký prostor při budoucí refaktorizaci nebo ladění) a výkon (na aplikační vrstvu dotahujete jenom data, která potřebujete a spousta operací prbíhá na straně databáze v nativní podobě - taky asi lépe budete využívat cachovací mechanizmus databáze, ale to záleží na konrétním příkladu).

Pro někoho může být nevýhodou, že se bude muset naučit procedurální programování na straně databáze. V každém případě to bude mít přínos, protože zjistíte, že některé věci můžete pomocí databázových procedur řešit velmi efektivně. Otázkou je, jestli to v tomto případě není "kanon na vrabce" :-) chcete-li však rozšířit rozhled, určitě to má smysl vyzkoušet - až se setkáte s velkým projektem, bude se to hodit.

Navržený postup samozřejmě můžete ještě modifikovat, pokud by aplikace byla nasazena do podnikové infrastruktury nebo pokud používáte centralizovanou správu uživatelských práv (třeba LDAP).

Nahlásit jako SPAM
IP: 85.71.61.–
klinki0
Návštěvník
4. 2. 2008   #6
-
0
-

To stepan : Tohle reseni vypada take zajimave - akorat by me zajimalo jestli by bylo mozne neco takoveho zrealizovat na MySQL 5.1 databazi? Vim, ze stored procedury podporuje, ale nevim jestli podporuje uplne vsechny potrebne vlastnosti atd.. Predpokladam, ze u PostgreSQL by to takovy problem byt nemel, ze? A alespon se naucim neco noveho co se tyce databazi :)

Nahlásit jako SPAM
IP: 85.13.98.–
stepan0
Newbie
4. 2. 2008   #7
-
0
-

To klinki : Projekt jsme implementovali na platformě Oracle. Domnívám se však, že na základní úkony by mělo MySQL nebo PostgreSQL stačit - bohužel s tím nemám zkušenost. Vyzkoušejte a uvidíte :-)

Nahlásit jako SPAM
IP: 80.95.102.–
klinki0
Návštěvník
4. 2. 2008   #8
-
0
-

Aha :) No nejdriv nekde nastuduju procedury atd.. abych to pak mohl vyzkouset :)
Na tom PostgreSQL by to snad problem byt nemel

Nahlásit jako SPAM
IP: 85.13.98.–
Zjistit počet nových příspěvků

Přidej příspěvek

Toto téma je starší jak čtvrt roku – přidej svůj příspěvek jen tehdy, máš-li k tématu opravdu co říct!

Ano, opravdu chci reagovat → zobrazí formulář pro přidání příspěvku

×Vložení zdrojáku

×Vložení obrázku

Vložit URL obrázku Vybrat obrázek na disku
Vlož URL adresu obrázku:
Klikni a vyber obrázek z počítače:

×Vložení videa

Aktuálně jsou podporována videa ze serverů YouTube, Vimeo a Dailymotion.
×
 
Podporujeme Gravatara.
Zadej URL adresu Avatara (40 x 40 px) nebo emailovou adresu pro použití Gravatara.
Email nikam neukládáme, po získání Gravatara je zahozen.
-
Pravidla pro psaní příspěvků, používej diakritiku. ENTER pro nový odstavec, SHIFT + ENTER pro nový řádek.
Sledovat nové příspěvky (pouze pro přihlášené)
Sleduj vlákno a v případě přidání nového příspěvku o tom budeš vědět mezi prvními.
Reaguješ na příspěvek:

Uživatelé prohlížející si toto vlákno

Uživatelé on-line: 0 registrovaných, 7 hostů

Podobná vlákna

Efektivni promenne. — založil LukAss741

Efektivní dědičnost — založil Martin

Zmena prav — založil aranes

 

Hostujeme u Českého hostingu       ISSN 1801-1586       ⇡ Nahoru Webtea.cz logo © 20032024 Programujte.com
Zasadilo a pěstuje Webtea.cz, šéfredaktor Lukáš Churý