Diskuze: Jak co nejefektivněji řešit uživatelská práva?
V předchozím kvízu, Online test znalostí PHP, jsme si ověřili nabyté zkušenosti z kurzu.
Zobrazeno 9 zpráv z 9.
K personalizaci obsahu a reklam, poskytování funkcí sociálních médií a analýze naší návštěvnosti využíváme soubory cookie. Informace o tom, jak náš web používáte, sdílíme se svými partnery pro sociální média, inzerci a analýzy. Partneři tyto údaje mohou zkombinovat s dalšími informacemi, které jste jim poskytli nebo které získali v důsledku toho, že používáte jejich služby.
Používáme nezbytné cookies pro fungování webu a s tvým souhlasem také analytické a marketingové cookies.
Zajišťují základní funkce, bezpečnost a služby, které sis vyžádal. Nelze je vypnout.
| Služba | Poskytovatel | Účel | Cookies a úložiště | Doba uložení |
|---|---|---|---|---|
| ITnetwork | ITnetwork | Provoz webu, relace, přihlášení a uložení nastavení cookies. | PHPSESSID, auth_token, sid, itn_consent_impression, __Host-itn_consent | Relace až 1 rok |
| Google Tag Manager | Správa značek a načítání měřicích nástrojů webu. | Žádné | Neukládá se | |
| Google Fonts | Načítání typografie webu. | Úložiště řízené poskytovatelem | Dle podmínek poskytovatele | |
| Google Hosted Libraries | Načítání potřebných knihoven a stylů webu. | Úložiště řízené poskytovatelem | Dle podmínek poskytovatele | |
| Google reCAPTCHA | Ochrana formulářů a webu před zneužitím. | _GRECAPTCHA, rc::a, rc::b, rc::c, rc::f | Relace až 180 dní | |
| YouTube | Přehrávání vloženého video obsahu. | localStorage, IndexedDB; cookies after playback interaction | Relace až trvalé úložiště | |
| Vimeo | Vimeo | Přehrávání vloženého video obsahu. | __cf_bm, _cfuvid, vuid, localStorage, IndexedDB | Relace až 2 roky |
| Facebook Login | Meta | Přihlášení pomocí účtu třetí strany. | Úložiště řízené poskytovatelem | Relace až 1 rok |
| GoPay | GoPay | Zpracování uživatelem vyžádané platby. | Úložiště řízené poskytovatelem | Dle podmínek poskytovatele |
Pomáhají nám porozumět používání webu a zlepšovat ho.
| Služba | Poskytovatel | Účel | Cookies a úložiště | Doba uložení |
|---|---|---|---|---|
| Google Analytics 4 | Měření návštěvnosti a používání webu. | _ga, _ga_* | Až 2 roky | |
| Microsoft Clarity | Microsoft | Měření návštěvnosti a používání webu. | _clck, _clsk, _cltk | Relace až 1 rok |
Slouží k měření kampaní, personalizaci reklamy a marketingové komunikaci.
| Služba | Poskytovatel | Účel | Cookies a úložiště | Doba uložení |
|---|---|---|---|---|
| Google Ads | Měření kampaní, reklama a remarketing. | _gcl_au, _gcl_ls | Relace až 90 dní | |
| Meta Pixel | Meta | Měření kampaní, reklama a remarketing. | _fbp, _fbc, localStorage | Až 90 dní |
| Sklik | Seznam.cz | Měření kampaní, reklama a remarketing. | retargeting, sid, szn:* | Relace až trvalé úložiště |
| LinkedIn Insight | Měření kampaní, reklama a remarketing. | bcookie, li_gc, lidc, __cf_bm | Relace až 1 rok | |
| Ecomail | Ecomail.cz | Měření kampaní, reklama a remarketing. | ecmid, Úložiště řízené poskytovatelem | Dle podmínek poskytovatele |
| Atribuce kampaní ITnetwork | ITnetwork | Přiřazení návštěvy a objednávky ke kampani. | campaign_clid[*], user_session_context | Až 1 rok |
V předchozím kvízu, Online test znalostí PHP, jsme si ověřili nabyté zkušenosti z kurzu.
Tabulka s uzivateli, Tabulka s pravy
One/ManyToMany relationship
To mě napadlo, spíš řeším jestli jedno právo jeden sloupec a nastavovat true/false nebo tam ukládat třeba string read/edit/NULL nebo pod právo na ten jeden modul(sloupec v DB) sdružovat nějaká pod-práva? Ptám se, jak se to používá v praxi..
Můžeš to dělat jakým způsobem chceš(jaký je nejvhodnější pro danou aplikaci).
Já to mam tabulku takto:
| id | role_name |
| 1 | ROLE_USER |
| 2 | ROLE_ADMIN |
V php mam vlastni funkci is_granted() ktera zjišťuje jestli uživatel ma danou roli.
if(!is_granted('ROLE_ADMIN'))
{
die('přístup zamítnut');
}
Samozřejmě 1 uživatel může mít více rolí, takže potom ověření vypada nějak takhle
if(!is_granted('ROLE_ADMIN') && !is_granted('ROLE_EDITOR') )
{
die('přístup zamítnut');
}
Tohle je únosné do určité míry, pokud to má být komplexnější
projekt, tak nastupuje ACL - access control list.
Snad všechny větší frameworky nabízejí nějakou funkcionalitu pro tento
přístup k uživatelským oprávněním. Nette, Zend atd. Nette má k tomuto
tématu pěknou dokumentaci, tak doporučuji pročíst. Nette
ACL
Nadefinuješ si role - např. guest, member, power user, admin,
superadmin.
Nadefinuješ si zdroje - např. administration, article, profile...
Nadefinuješ akce - např. view, edit, create
A následně nastavíš, co kdo může => allow(guest-article-view),
deny(guest-administration-view) a pak už se pouze v aplikaci na konkrétním
místě zeptáš, zda přihlášený uživatel má povoleno provést akci s
daným zdrojem. Pokud použiješ nějaký komplexnější systém, tak by si
měl framework sám zjistit, u jakého zdroje se nachází a jaká práva user
má.
Samozřejmě lze využít dědičnost rolí - co může guest, to může logicky i admin - obráceně to ale nefunguje.
Zkus se na to podívat, uvidíš. 
Tohle mi příjde už jako overkill.
Tohle bych využil tak maximálně na nějaký projekt ala Magento.
uživatelská práva pro nějaký větší systém kde máte třeba více modulů
Já s tím overkillem tak úplně nesouhlasím - sice jsou tam počáteční
investice času do toho, aby člověk pochopil jak to funguje a jak to
implementovat, ale podle mě se ta investice vyplatí. Mít na jednom místě
konfiguraci všech práv a v aplikace se pouze ptát, zda pro to má
oprávnění, mi přijde jako čisté a hlavně přehledné řešení.
Samozřejmě u nějakého zabezpečení administrace pro jednoho uživatele je
to absurdní, ale zrovna u modulů, více úrovní uživatelů atd. bych to už
znova nechtěl řešit jinak.
Ale samozřejmě je to na každém z nás, jakou cestu si vybere.
Zrovna u frameworků je to podaná
ruka a proč ji nevyužít.
To maš pravdu, že to záleží na daném programátorovi.
Jinak např. Symfony už defaultně nenabízí ACL(pokud ho chceš, musíš si ho doinstalovat).
Zobrazeno 9 zpráv z 9.
