Viacnásobný IAuthenticator pre viacej modulov?
- hAssassin
- Člen | 293
Zrovna tohle jsem taky řešil a nemělo by být problém si autentikátor nastavit vždycky před přihlášením v callbacku příslušnýho formuláře (viz tady):
$this->user->setAuthenticator($authenticator);
$this->user->login($values->username, $values->password);Ale měl bych otázku: dejme tomu že mám moduly Admin a Front a oba jsou na sobě nezávislé co se přihlašování týče (Admin má administrátory uloženy v tabulce ‚admins‘ a Front v tabulce ‚users‘). Výběr autentikátoru při přihlášení není problém, ale jak ověřit zda se do Admina nepokouší dostat někdo kdo už je přihlášenej ve Frontu? Vím existují jmené prostory ale tohle je dost stručný. Jak to tedy používat? Teda resp. jde to vůbec bez nutnosti ověřovat roli uživatele?
- hAssassin
- Člen | 293
to 22 > tím si nejsem úplně jistý, ale ok. Jen by mě zajímalo jak by si tedy ten autheticator řešil? měl bys všechny uživatele (obou modulů) v jedný tabulce a rozhodoval se podle role? Případně jak rozlišíš, že do tohohle modulu může uživatel s rolí ‚Registred‘ a do jinýho zase uživatel s ‚Admin‘? Nebo bys na to šel úplně jinak?
to gmvasek> takže namespace nastavit vždy po volaní $user->login() ? Co mi pořád ovšem nejde do hlavy je to, jak zjistit ve kterým namespace je aktuální uživatel právě přihlášen. Resp. vidím to tak, že pokud je přihlášenej ve Frontu a přejde do Admina, tak by ho to mělo hodit na stránku přihlášení do admina, tady ale asi $user->isLoggedIn() nepostačí ne? Případně, pokud se uživatel přihlásí do novýho namespace tak ho to v tom původním odhlásí nebo ne?
- hAssassin
- Člen | 293
Tak ješte trochu spamu :-)
@22 > asi máš pravdu, na jednodušší věci to stačit bude, jen nevím by to stačilo i kdyby byly 2 Front moduly (na sobě nezávislí) a každý by měl vlastní registraci. Třeba jako tady: wiki a forum (ikdyž tady to asi bude společný, ale jde mi o ten princip)…
Jinak ty namespace asi chapu, ono asi bude stačit nastavit namespace v BasePresenteru (třeba ve startup()) danýho modulu a pak to kontroluje podle akutálního namespace. Nemám pravdu? (zkouším to a zda se že to tak bude:-)
- Filip Procházka
- Moderator | 4668
Přesně tak, čím složitější aplikace, tím víc potřebuješ ACL. A dvě registrace na stejný web, byť se dělí na wiki a fórum? Co to je za blbost? :) Říká ti něco uživatelská přívětivost? :)
Authenticator představuje způsob přihlášení. Tzn že máš
třeba ApiAuthenticator,
UsernameAndPasswordAuthenticator, CodeAuthenticator
(ty názvy samozřejmě přeháním, jsou jen pro ilustraci funkčnosti)
Naproti tomu Authorizator představuje povolení přístupu na
určitou akci. Tzn presenter, model, …
- hAssassin
- Člen | 293
HospiLan > uznavam, moje chyba, s jednim authenticatorem to
je lepsi. me trochu matlo, ze sme neco podobnyho resili asi pred rokem v praci,
teda ja to primo neresil (to kolega), ale vim ze se pridavala k e-shopu nova
sluzba a ta mela rozdilnou registraci a prihlasovaci udaje nez puvodni e-shop
(ale uz si moc nepamatuju detialy… ehm, teda vubec :D, jen me to ted
zmatlo).
Kazdopadne, authenticator jeden, ale authorizatoru
muze byt teoreticky vic (treba pro kazdy modul zvlast)? Nebo taky jen jeden?
Nebo zase kecam nesmysly? :)
- Filip Procházka
- Moderator | 4668
Authorizator představuje logiku, která něco povoluje a
v Nette je jeden hotový, měl by ti stačit. Tzn že do něj si nastavíš co
kdo může a nemůže a pak se ho budeš ptát. Více si přečti zde, doporučoval
bych to nastavení ukládat do databáze a kešovat vytvořený a nastavený
objekt.
- hAssassin
- Člen | 293
HospiLan > jj kecal sem nesmysly. Byl sem dost unavenej po ranu tak mi to
nemyslelo :D O Permission vim a pouzivam ji, teda resp. nechtel se
mi load roli, zdroju a opravneni davat primo do Application nebo
nekam do BasePresenteru, takze sem z Permission
podedil MyPermission a v jeho konstruktoru ty role a vsechno
vytvarim. Myslim ze takhle to je good, ze?
P.S. samo ze MyPermission mam regnuty jako sluzbu
authorizator…
Editoval hAssassin (30. 6. 2011 18:18)
- Filip Procházka
- Moderator | 4668
No v Application nebo v BasePresenteru bych to
určitě nedělal :) Spíš bych si podědil, jak ty říkáš, nebo udělal
nějaký builder, předal mu spojení do databáze, popř nějakou service co to
načítá a tam to poskládal :)
Protože tohle je takové nešikovné na údržbu, ale je ok :)
- Peppy
- Člen | 137
Ahoj, tak som tu spať…čítam to znova a znova a nejako mi to nezapadá do plánu…mám proste admin modul, ktorý je ODDELENÝ od zvyšku aplikácie (tzn. pracuje samostatne, nie je závislý na iných moduloch a tabuľkách), proste je to akýsi control panel. Do neho majú prístup iba rooti, ale nie napr. admin fóra atp. No na to aby administračný backend pracoval (pracuje na vlastných tabuľkách) musí mať autorizačný handler úplne iný (lebo berie z inej tabuľky userov (__roots__ tabuľka))…čo vy na to?
- Filip Procházka
- Moderator | 4668
Nenapadá mě rozumný důvod, proč mít rooty oddělené od
obyčejných uživatelů. Navíc, brzy narazíš, až si klient vymyslí, že
chce jednomu adminovi dát tato oprávnění a druhému tato.
- Peppy
- Člen | 137
Tak normálne na ACL ?? Všetko do jednej tabuľky users a tam
to hľadať?? Ide o to, že ten modul (napr. fórum) sa môže meniť a ja
neviem, či, a ako sa bude ten modul správať a či to vôbec bude napríklad
fórum. Môže to byť napr. nejaké portfólio, ktoré tabuľku potrebovať
nemusí…a zase s každým modulom sa menia požiadavky na databázu a
tabuľky, preto nemôžem urobiť nejakú stacionárnu users
tabuľku a povedať im, aby do tabuliek nijako nešahali…
Má to byť modulárna aplikácia, ako hovoríte „se vším všudy“, to platí aj pre databázu…
Editoval Peppy (5. 7. 2011 14:33)
- Filip Procházka
- Moderator | 4668
To ale přece není problém :) Stačí aby tabulky linkovaly
users, né naopak. Pak nebudeš muset upravovat users
ani jednotlivé acl_*, budeš jen přidávat záznamy.
A moduly by měly používat vlastní tabulky, popř. max vyžadovat
přítomnost nějakého sloupce v users (a dalších), pokud je
nezbytně nutné, aby v ní byl. Pak můžeš mít nějaký
Manager, který moduly projde a splní jejich požadavky. Čili
tyto sloupce vytvoří, nebo smaže. To samé tabulky.
Kde je problém?