Znovupoužitelné komponenty a autorizace

Nikdo nic? :( Ke kterému řešení byste se přikláněli vy? Ke vstřikování autorizátoru, nebo k použití události? Co je podle vás vhodnější? Řešil jste někdo něco podobného? Pokud tady plácám blbosti, tak se omlouvám.

3. Komponenta sama o authorizaci nic netuší, případná práva na její zobrazení hlídá továrnička v presenteru. Kontrolu práv před smazáním si kontroluje samotný model. Komponenta tedy z práv zná jen výjimku, kterou má odchytit a vypsat že uživatel nemá práva.

S tím zase nesouhlasím já. Model není jen nějaký dotazovač, tím je ORM. Model by měl být jádro aplikace, který si sám hlídá konzistenci a chrání bezpečnost. Modelu je sice jedno, jestli se uživatel identifikuje heslem, tokenem, nebo čím chce. Ale jestli ten uživatel může něco dělat, to by si měla hlídat nějaká vrstva hned nad repository. (Ano, repository se má jen starat o db (resp. úložiště) a nikoliv o oprávnění. Ale model ≠ repository.)

Jinak oprávnění na zobrazení komponenty/pohledu si samozřejmě řeší presenter. Ale i kdyby se zobrazilo třeba mazací tlačítko uživatelovi, který nemá práva mazat, tak to nesmí ohrozit bezpečnost modelu.

Editoval Šaman (7. 8. 2014 7:00)

Díky za odpovědi. Svým způsobem mi nová vrstva mezi komponentou a samotným repository, která se by se postarala o autorizaci dává smysl, ale nejsem si jistý, že to řeší můj problém. Kontrolu v továrničce v presenteru samozřejmě provedu, ale tím maximálně zabráním tomu, aby se ta komponenta nevytvořila, neřeší to problém, kdy mám v komponentě signál a právě v něm musím rozhodnout jestli má uživatel právo operaci dokončit, nebo ne. Logika celé operace je v komponentě, data, o kterých rozhoduji, jsou v komponentě, tak musím podle mě v komponentě také rozhodnout, nebo toto rozhodnutí delegovat někam dál. Ale právě si moc nevím rady s konkrétním řešením :-/ Ale ještě nad tím popřemýšlím, třeba je ta vrstva mezi komponentou a repository právě to, co hledám.

Me se libi resit to eventem signalu komponenty napr. beforeDelete primo v prezenteru.

Prezenter rozhodne a komponenta nemusi resit pri signalu nic.

Event se mi taky na pohled celkem dost líbí, problém je v tom, že se na něj nemůžeš spolehnout. To pak přichází v úvahu ještě nějaká autorizační vrstva mezi komponentou a modelem (jak popisuje např. Šaman), která ti zaručí, že nedojde k operaci, ke které dojít nemá. Problém s eventem je ten, že nesmíš zapomenout na něj navěsit v presenteru (nebo někde jinde) odpovídající kontroly – 100× nezapomeneš, ale po 101 můžeš a hned je bezpečnostní díra na světě. Takže event maximálně jako nějakou doplňkovou záležitost, která třeba zabrání vykreslení nějakého prvku (odkazu, tlačítka), ale nesmíš na ní přenést celou odpovědnost za autorizaci.

Právě v tom presenteru. Já vím – jaká je pravděpodobnost, že na něco tak očividného zapomeneš, ale stát se to IMHO může. Jinak ten způsob, že bych si to navěsil takhle v presenteru se mi právě hodně líbí.

Editoval jannek19 (19. 8. 2014 15:39)

Nechtělo se mi to řešit přez Kdyby\Events, a myslel jsem to nějak takto:

class ExamplePresenter
{
	protected createComponentExample()
	{
		$control = $this->exampleFactory->create($this->user->id);
		$control->onRestriction[] = function($control){
			if($isAllowed = $this->user->isAllowed( ... )){
				$control->setEditable();
			}
		};
		retrun $control;
	}
}

a v komponentě už jen pouštet $this->onRestriction() a v ty restrikci by se dali předávat i ty parametry restrikce, ale asi je to zbytečné delegování zodpovědnosti někam jinam, a zatěžování presenteru.

Možná má tedy ten Šamanuv způsob řešit restrikce přímo v modelu něco do sebe.

Editoval jenicek (20. 8. 2014 14:40)

Ok presne to delam tim editable, ktere predavam do sablony komponenty eventem a v komponente tedy nepracuji s autorizaci. Je to blbe?

Mozna staci jen setEditable pro komponentu a defaultne ji mit needitovatelnou.

Editoval jenicek (21. 8. 2014 10:40)