Session a uživatelská skupina – PHP – Fórum – Programujte.com

Ahoj všem,

prosím si radu ohledně uživatelské skupiny, myslíte si, že je vhodné, abych při přihlášení uživatele vytvořil session která ponese informaci jakou má uživatelskou skupinu?:

session_start();
$_SESSION['login'] = stripslashes($login);

$_SESSION['login'] = stripslashes($skupina);

Potom bych měl jen na určitých částeh stránky funkce které by se pomocí této session ptala databáze zda má oprávnění například pro přístup ke stránce nebo se stisknutí tlačítka, či odstranění záznamu apod. Funkce by vypadaly jako MáOprávněníOdstranitZáznam($_SESSION['login'], $idZaznamu) nebo kontrola zda se má zobrazit tlačítko, jestli ho má vidět nebo ne MáOprávněníVidětTlačítko($_SESSION['login']), apod.

Nebo se to v praxi řeší jinak? Jak byste to řešily Vy? Upozorňuji, že to nepíši v OOP, ale jako strukturální gulášek, teď toho lituji.

Díky všem za názor, případně radu jak na to jít jinak. Ale názory typu smazat a udělat znovu v OOP bych viděl nerad, protože už je to skoro hotové.

#1 fix
Autorizaci dělám až jako součást SQL dotazu. Pokud někomu změním oprávnění, nemusí se kvůli tomu odhlašovat a zase přihlašovat.

BTW: K čemu je dobré použití funkce stripslashes()?

Hele ani nevím, asi sem to zkopíroval již s example pro přihlašovací formulář. :-D

Jasně udělám to taky tak, před načtením obsahu stránky zavolám nějakou funkci, která složeným dotazem vyčte z DB veškerá oprávnění a podle vyýpisu z DB sestaví stránku, tak, aby to odpovídalo uživatelské skupině uživatele.Díky.

#3 fix
Ono se to dá vložit přímo do toho výpisu - místo dvou SQL dotazů stačí jeden.

#4 Kit
Teď vůbec nevím o čem píšeš, nespletl sis vlákno?

Případně nějaký kod pro ukázku bys prosím neměl?

Jak jsem to napsal já, že to udělám, tak je to špatné řešení?

Jako výpisy mám joinem sloučené uživatele a záznamy které mají vidět, to jo. Tam mám selekci už v dotazu pro výpis.

#5 fix
Do session si po přihlášení uložíš ID uživatele. Nic víc.

Při dotazu na seznam stránek napíšeš ten SQL dotaz asi takto: 

$userId = $_SESSION['userId'];
$sql = "SELECT article.* FROM article
    JOIN user ON article.group_id=user.group_id
    WHERE user.id=$userId";

Předpokladem je, že uživatel je členem maximálně jedné skupiny. Pokud by mohl být ve více skupinách, bude struktura tabulek trochu odlišná a dotaz bude o jeden řádek delší.

BTW: Psal jsem to z hlavy, snad v tom není chyba.

Spravne bys mel overovat login a opravneni uzivatele pokazde, kdyz je to kriticky dulezite. Zmeny udaju (UPDATE, DELETE, INSERT) nebo cteni udaju (SELECT), ktere nema jiny uzivatel videt. Idealne vzdy, vsechno.
Napr, aby bezny uzivatel nemohl zjistit prihlasovaci jmeno admina, takze vsechny dotazy, co pristupuji do tabulky uzivatele, napr. Ale mene dulezite muze pro tebe byt, ze se uzivatel dostane k pripravovanemu nezverejnenemu clanku. Ikdyz, tohle by mohlo zas zajimat konkurencni casopis, mohl by clanek vydat driv a ziskat vic prodeju.

Otazkou je, co do session davat.
Muzes tam dat login, psw. Ale, kdyz to bude prohlizet hacker, bude vedet primo login.
Muzes tam davat pseudo-hash, ktery si ulozis do tabulky id_uzivatel, pseudo-hash. To je o neco lepsi, platnost potrva jen dokud je uzivatel prihlasen, nebo das limit 5 min a bud se vygeneruje novy nebo ho to auto-odhlasi. Ale, pokud nekdo sleduje linku, muze stejne podvrhovat akce. Takze by hashe mohla byt soucasti ip a nejake dalsi identifikacni udaje, rozmery okna a jine.

Ja to resim v kazdem programu jinak. Do session davam loginy, hashe. Delam si v php promenou $UZIVATEL. Ale neni to spravne reseni. Spravne by ses mel pokazde zeptat sql. To uz mam take v kritickych programech. Jde o to, ze, pokud se hackerovi podari pres formular obejit nejake kontroly a nastavi si v $UZIVATEL login na admin, skupinu na admin, tak, pokud neoveris i heslo uzivatele, tak mu dovolis treba vytvaret administratory nebo zmenit jinemu uzivateli prava na admina.

Jeste se da udelat superadmin uzivatel. Nekdo, kdo ma login zapsany v externim souboru a vubec ne v db. Pokud nekdo zcizi db, tak tam by mel jen loginy beznych uzivatelu s beznymi pravy.

#6 Kit
Jo, přesně takhle mám výpisy do tabulky, ale výpisy jsou jen jedna část, ale když v tom selectu vypíši více atributů. Akorát v session neuchovávám id, ale login.

#7 peter
Super, díky moc za moc super informací. Taky dělám asi blbost, že do session ukládám něco jako $admin = 1 nebo 0; :-D

Každopádně, na generování hashů apod kašlu, nejde o citlivá data a nechci to s tou bezpečností přehánět.

S bezpecnosti se neda prehanet. V podstate zadnou nemas, jak to popisujes. Potrebujes tak 75% a mas tak 5% :) Admin=1 zkusi hacker na prvni pokus. Az pak zacne zkouset hesla a tak.

Ted mne jeste napadlo, ze u db je vlastne dobre udelat uzivatele admin, uzivatel, moderator. Pokud muzes delat vlastni uzivatele. Kazdemu dat jina prava pro konkretni tabulky. Pokud bude sql dotaz nad tabulkou, kde nema bezny user prava, tak mu nastaveni admin=1 nebude nic platne, pokud bude v sql prihlaseny jako user z predchozi stranky.  A mas dalsich 10% navic, treba :)

#10 peter

To jo no místo admin tu proměnnou nazvu nejak jinak, třeba opravneni731 :-D Díky za upozornění, to mi vůbec nedošlo. Člověk se musí napřed hackovat, aby věděl web udělat pořádně. :-)

Jinak položit admin rovno 1 mu nepomůže stejně bude muset dosadit do databáze hash s heslem, ale když je to v době, kdy má přístup ke zdrojovým souborům, tak je to hračka.

No když už sme zabředli do tohodle. Chtělo by se ti mě poučit jak by se hacker dostal k tomu aby mohl upravit session?

#11 fix
Pokud tu aplikaci nezvořeš, tak se hacker k modifikaci session nemá jak dostat.

Já si taky právě myslím a když zvořu a dostane se k editaci session, tak už stejně název té proměnné přece nehraje roli. Takže mám na salámu. :-) Díky za vysvětlení.

Lepe pocitat s tim, ze je mozne vsechno a mit zalozni plan :) Pokud ti jde fakt o bezpecnost. Neco necekaneho. Treba nejakou past. Jako, do linku pridat admin=1, ale v programu to ignorovat. Vypsat uzivateli treba jakoze je prihlasen jako admin (aby mel pocit, ze to funguje), ale v programu mu pridelit user prava nebo dokonce guest.

A vubec, nebudu ti psat, ze treba neco nedelam nebo, jak to resim, nikdy nevis, kdo to cte. Nepotrebuji, aby vedel nekdo tak moc informaci o tom, jak moc nebo malo zabezpecuji :)