Diskuze: Uživatelské role

Tvůrce

Zobrazeno 15 zpráv z 15.
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 |


Nejlepší je obojí. Teď jsem použil pevné role a lehce toho lituji, asi
to stejně předělám na určitá oprávnění.
Pro uživatele jsou přednastavené lehčí na obsluhu, ale hodí se i možnost
poupravit si je.
Je tu spousta faktorů. Pokud je aplikace určena pro administrátora,
očekávající plnohodnotnou aplikaci, musíš naprogramovat role i s
přispůsobením. Nejlépe v administraci úpravu rolí spolu s přispůsobením
práv.
Pokud je redakční systém pro tebe, bude lepší nechat přizpůsobení práv
na samotné logice aplikace. Při úpravě webu si můžeš pohodlně vyhrát se
složitostí práv, což by v administraci bylo poněkud obtížnější.
Pokud jde o počet rolí, zase závisí na několika faktorech. Nicméně pro redakční systém je osvědčená hierarchie: administrátor, editor, redaktor, člen. Kdy editor články schvaluje, redaktor publikuje. Počet rolí pak závisí na složitosti aplikace, nicméně na jednoduchý redakční systém by to mělo stačit.
Ještě bych trochu doplnil - otázka pro obě skupiny:
Jaký způsob řízení oprávnění je podle vás nejlepší?
Případně něco dalšího?
1 a 2 je přece to samé, role je skupina uživatelů. Tady není nad čím přemýšlet, každý dobře navržený informační systém to má takhle udělané. Úrovně oprávnění nebudou fungovat, v žádné reálné aplikaci nemáš role takhle lineárně za sebou, co tu padlo jsou jen učebnicové příklady.
1 a 2 není to samé.
U 1 znamená každá role nějaké oprávnění a uživatel jich může mít
kolik chce.
Ve 2. má skupina několik oprávnění a uživatel může být v jedné
skupině.
Číslo jedna a dvě se mi zdají stejné. Skupina s oprávněním = role. Je jedno jestli v databázi přiřazuješ ID role, nebo skupiny. Možná jsem ale nepochopil myšlenku. Nastavovat oprávnění ručně také není zrovna nejlepší nápad, nicméně stejně při registraci musíš uživateli nějakou hodnotu nastavit.
Osobně používám role, kterým v databázi přiřazuji oprávnění. Uživatelům pak při registraci (nebo změnách v administraci) přiřazuji roli. Pak by to mohlo vypadat takto:
Oprávnění
---------
id: 1
...
Role
----
id: 1
...
Oprávnění rolí
--------------
id_role: 1
id_opravneni: 1
Uživatelé
---------
id: 1
id_role: 1
// Edit: David byl rychlejší, takže poznámku o synonymitě jedničky a
dvojky ignoruj. 
Nevidím žádný smysl v entitě "oprávnění". Když má někdo roli "redaktor", tak prostě může psát články. Nic víc se v tom hledat nemusí, další informace není potřebná.
Napsal jsem to tak právě kvůli přispůsobování v administraci. Aby neměl administrátor pouze pevné předpřipravené role. Ale samozřejmě taky možnost.
Tam jde o to aby to bylo univerzální. Pokud to správně chápu, v kódu nastavíš že potřebuješ to a to oprávnění (např psát články a schvalovat je). Roli (skupině) pak nastavíš že má to a to oprávnění (např jenom psát články). Tu roli pak přiřadíš uživateli a podle toho jaká oprávnění má může provádět různé akce.
EDIT: Resp. do role přiřadíš uživatele
EDIT2: Píšu moc dlouho .. 
Uživatel má ty role, které mu naklikáš. Já tu mám asi 20 různých rolí. Kdybys chtěl, abych tu měl jen jednu (administrátor), tak mezi nimi implementuješ dědičnost. Pojem "oprávnění" mi přijde matoucí.
Teď jsem tě nějak nepochopil. Dokáže tvůj administrátor vytvořit novou roli podle svých představ, aniž by zasáhl do kódu? O to mi právě šlo. Možná jsem tě ale špatně pochopil. Nicméně je tisíce způsobů a každý to samozřejmě vymyslí jinak.
Oba chápeme role jinak, ty to máš postavené tak, že má uživatel jednu roli, která má více oprávnění. IMHO je logičtější, aby měl uživatel více rolí. Role potom funguje jako jedno tvé oprávnění.
Já bych použil několik rolí a uživateli přiřadíš kolik potřebuješ
- jako to máme tady. Aby uživatel moh mít pouze jednu roli, která by dědila
ty předchozí, to se jednou můžeš dostat do bodu, kdy najednou budeš
chtít, aby jeden člověk něco moh, ale jinej je. Například: Já sem
Správce vtipů. To je poměrně bezvýznamná role se skoro žádnými
oprávněními, takže bych s ní nic nedědil. Ale třeba Administrátor fóra,
což je role významější, by zdědil všechno, co je pod ní - včetně
Správce vtipů. A tady máš problém - na administraci vtipů chceš mít
jednoho, dva, ale takhle by ti tam lezli všichni admini. Ale pokud budeš moct
přiřadit několik rolí jen někomu bez dědění, tak se ti tohle nestane.
Snad sem se vyjádřil dost jasně 
Jasně, chápu co oba myslíte. Díky za rady 
Zobrazeno 15 zpráv z 15.