Neměl by IAuthorizator dostávat místo role celou indentitu?

Určitě by bylo logičtější, kdyby celá logika autorizování byla v IAuthorizator. Plus by odpadlo podstrkávání objektům IRole ID uživatele (https://forum.nette.org/…i-permission), přidá-li se do Permission metoda ala getQueriedIdentity. .)

(+1 .])

Editoval Yrwein (25. 6. 2011 13:19)

@Jan Tvrdík: Imho se to dá řešit podobně/stejně jako nyní s rolemi — pro účely autorizace se vytvoří fake identita s jednou rolí „guest“.

Editoval Yrwein (29. 6. 2011 13:22)

Tohle se sice už do 2.0 nedostane, ale dal bych tomu velkou prioritu. Kdyby někdo připravil RFC, bylo by to fajn.

Koukám, že tohle tady nějak zapadlo, nikomu se zřejmě nechtělo sepisovat RFC. Přiznám se, že nějak moc nevím co bych do toho RFC psal. Dneska už se to dá řešit tak že si do authorizatoru injectu celého usera, ale tohle by bylo lepší.

Díval jsem se jak velký problém by byl tohle implementovat. Bohužel by to ale znamenalo dost drastickou úpravu testů Permission a do toho se mi příliš nechce. Vše ostatní je trivka.

@Jan Tvrdík: Je někde k dispozici ukázka toho co používáš?

@David Grudl: Pokud bych se do toho přeci jen pustil, je šance mergnout to dříve než bude 2.1 final? Vadilo by něčemu kdybych úplně odebral IRole? Smysl tohoto rozhraní mi poněkud uniká.

Editoval enumag (22. 1. 2013 1:18)

Zkoušel jsem to vyřešit injectnutím Usera, dokonce to asi nějakou chvíli fungovalo, ale teď jsem se vrátil ke starému projektu, aktualizoval vývojovou verzi Nette a vyhazuje mi to kruhovou závislost, protože User teď vyžaduje v konstruktoru container (wtf?) ze kterého si vezme autenthicator a authorizator.

Připadá mi, že třída User dělá aktivně moc věcí, které by za ni měly řešit pasivně jiné třídy. Když chci vědět, zda má uživatel na něco práva, ptám se přece nějakého managera oprávnění a ne toho uživatele. To už můžu rovnou začít používat ActiveRecord.

Chápu, že je to vývojová verze, ale půlku věcí si nechat injectovat (storage) a druhou půlku tahat z contextu, to není vůbec hezké.

Takže staronová otázka, na které stojí použitelnost celé nettí autorizace: Jak v ACL zjistit id přihlášeného uživatele? Nebo je teď nějaký zcela jiný best practise?

Editoval Šaman (11. 4. 2013 4:53)

Aha, díky, context jsem našel v API dokumentaci a zapomněl jsem, že to je stable verze, nikoliv dev.

Cyklus vznikl tím, že aktuální implementace třídy User vyžaduje authorizátor. Tedy nemohu authorizatoru předat usera. Pokud authorizátor bude schopný vrátit v metodě getQueriedRole() skutečně objekt identity, tak to nepotřebuji injectovat a dál to neřeším. Ono to předávání aktuálního uživatele byl stejné spíš hack.

Osobně by mi byl milejší samostatný authorizátor, kterého bych se zeptal, zda uživatel má právo na nějaký zdroj. Pak je na mě, zda mu v parametru předám objekty, nebo jen název role a resource. Předávat autorizátor uživateli, abych se mohl ptát přímo jeho, to mi přijde trochu nečisté.

@castamir: Nechceš sepsat RFC? :-)

V tom případě mám otázku obecnějšího rázu – dá se v configu dostat k identitě přihlášeného uživatele? Když nemohu předat celého uživatele, identita by problém neměla dělat, jen nevím, jak ji v configu vytáhnout z @user.

Toto bohužel nefunguje. Navíc se vlastně nezbavím té kruhové zavislosti – authorizátor potřebuje při vytváření uživatele a uživatel se vytvoří, až se mu předá mimo jiné authorizátor.

Nakonec tu identitu řeším setterem v bootstrapu. Ale stydím se za to :)

Šaman napsal(a):

Nakonec tu identitu řeším setterem v bootstrapu. Ale stydím se za to :)

No jo, ale co když se odhlásíš nebo přihlásíš? Pak se aktuálně přihlášená identita kompletně vymění / smaže, ale tobě zůstává nasetovaná ta stará. Pravděpodobně se po přihlášení přesměrováváš, takže ten problém není potřeba řešit. Ale chci poukázat na to, že identita je spíše value object, takže její nedostupnost jako servisy je naprosto v pořádku.

@Šaman:

Nepohnulo, protože David to chce jinak. Před pár dny jsem z toho RFC udělal extension, ale ještě jsem ani neměl čas vyzkoušet, že opravdu funguje. Máš-li zájem to extension použít, mohu ho hodit na GitHub, ale použití je na vlastní nebezpečí. ;-) Předem upozorňuji, že to extension je psané pouze pro Nette 2.1, pro 2.0 by sis to musel upravit.

Ostatní používají buď hack na který jsem odkázal v RFC nebo nějakou vlastní implementaci bez IAuthorizatoru. Že to neumíš se současným autorizátorem napsat mne nepřekvapuje, řekl bych, že to neumí nikdo.

Editoval enumag (27. 6. 2013 15:20)

Jak to zatím vypadá s nějakou úpravou? Mám v aplikaci trochu komplikovanější přidělování privilegií a zatím nejefektivnějším způsobem pro mě zůstává identita se všemi možnými informacemi. Jinak bych musel při každé žádosti pokládat dotaz(y) do databáze, což mi nepřijde ideální.