V Error4×xPresenteru nefunguje handle<signal> komponenty

Řeším ten samý problém a nevím si s tím rady. Já na férovku (jako znouzecnost řešení) dal natvrdo link: <a href=„/?do=navigation-openModal“ class=„ajax“>…, kdy volám handler by správně měl být <a href=„{link openModal!}“…, když volám URL kde není 404 tak to funguje.

Prakticky by stačilo, kdyby se dal podvrhnout v ErrorPresenteru komponentám jiný presenter.

Díky moc, vyzkouším :)

Další testování ErrorPresenteru a Error4xxPresenteru přineslo důležité poznatky:

Jak jdou jednotlivé requesty při výjimce za sebou jsem prozkoumal v Tracy panelu DIC ve službě application.application, parametr requests.

ErrorPresenter obdrží Nette\Application\Request s method = ‚FORWARD‘

Error4xxPresenter také obdrží Nette\Application\Request s method = ‚FORWARD‘

Mám to v projektu tak, že Error4xxPresenter dědí z BasePresenter, tím podědí i všechny globální komponenty a služby pro ně:

final class Error4xxPresenter extends BasePresenter
{
	public function startup(): void
	{
		parent::startup();
		if (!$this->getRequest()->isMethod(Request::FORWARD)) {
			$this->error();
		}
	}

    public function beforeRender()
    {
        parent::beforeRender();
        $this->setLayout('error-layout');      // @error-layout dědí z @base-layout ;)
        $this->template->robotIndex = false;   // při 404 nadbytečné, ale raději to tam dávám
    }

    public function renderDefault(?BadRequestException $exception = null): void
    {
        $this->template->httpCode = $exception?->getCode()? 404; // toto je VELMI VELMI důležité, GET/POST => 404 !!!
        $this->template->setFile($this->appDir . '/templates/Error/400.latte');  // používám jednu šablonu pro všechno
    }
}

Když přidám routu jak jsem ukázal kód o příspěvek výše, tak generování linků na signály funguje, ale co nefunguje je zpracování v presenteru handle<Signal>. Blokování provádí Nette Framework a sice kvůli property method=‚FORWARD‘ Nette\Application\Request-u který je v Error4xxPresenter-u. Když půjdeme na routu Error4xxPresenter-u přímo z url, tak to zase skončí chybou kvůli tomuhle:

	public function startup(): void
	{
		parent::startup();
		if (!$this->getRequest()->isMethod(Request::FORWARD)) {
			$this->error();	          // kód z nette/web-project nepustí požadavek GET do error presenteru - proč?
		}
	}

Vyhození výjimky $presenter->error() jsem zakomentoval a ověřil, že přístupem z url, kdy je method=‚GET‘ zpracování signálů funguje.

Nojo, jenže Nette Framework automaticky podstrčí do forwardnutého presenteru request s metodou ‚FORWARD‘. To je naprosto v pořádku, takhle to být asi musí, ale problém je ten, že se tím na jedné straně zablokují signály, ale v dokumentaci Nette je forward na jiný presenter prezentován jako legální způsob jak přehodit zpracování requestu na jiný presenter víceméně na úrovni přesměrování $presenter->redirect(). Bezpochyby by bylo dobré do dokumentace vysvětlit, jaký je zamýšlený účel forwardu na jiný presenter a zda by se měl/neměl běžně používat + upozornit na to, že při forwardu jsou signály blokované (kvůli bezpečnosti?). Já si netroufám tohle do dokumentace zodpovědně psát, protože jde o zpracování výjimek a otázku bezpečnosti. Zde je nezbytná součinnost autora @DavidGrudl , ten ví proč při ‚FORWARD‘ blokuje Framework signály.

Takže, necháme forward z ErrorPresenteru na Error4xxPresenter být jak je a zaměříme se na to, jak zprovoznit signály. To je naštěstí velmi, velmi jednoduché. Protože díky routě Error4xxPresenter-u se generují GET linky na Error4xxPresenter, tak signály jdou přímo metodou GET (formuláře POST) na Error4xxPresenter. Ten jak jsem si udělal dědí z BasePresenteru a tam obsluha signálů je. Takže nechme požadavky GET/POST žít:

	public function startup(): void
	{
		parent::startup();
		if (!$this->getRequest()->isMethod(Request::FORWARD)) {
//			$this->error();   // necháme projít i požadavky GET/POST
		}
	}

a to je všechno. Máme velmi jednoduchý a nativní způsob jak zajistit, aby na 404 stránce byl normální layout včetně zpracování signálů komponent i formulářů. Netestoval jsem jestli i ajaxové signály fungují, ale proč by neměly?

Blokovat signály pro ErrorPresenter je jasné, ale pokud člověk ví co dělá a dá si pozor, tak mě nenapadá důvod proč blokovat na vstupu do Error4xxPresenteru GET i POST a proč by nemohl mít Error4xxPresenter svoji routu. Tak jako tak se na té GET/POST routě uživateli vykreslí 404 – to je právě naprosto klíčové, člověk musí naprosto přesně vědět, že musí Error4xxPresenter dobře zabezpečit.

Současně jsem v kódu nette/web-project skeletonu objevil, že autor skeletonu pro nette/web-project asi zamýšlel, že by ErrorPresenter měl z requestu vysosat modul a separátor a forwardnout pro každý modul na samostatný Error4xxPresenter. To je skvělá myšlenka, protože pak je naprosto jednoduché, aby každý modul vykresloval svoje 404 do svého layoutu a 404stránky se mohly modul od modulu řešit individuálně.

Jenže je tam CHYBA (pokud se samozřejmě nemýlím já, což je dost často), protože se sosá jméno modulu ze špatného requestu – je potřeba jít o jeden request v historii requestů zpátky. Takhle jak to tam je udělané vyjde vždycky aktuální presenter Error a modul žádný (při standardní konfiguraci v common.neon). Sice to funguje, ale ne tak, jak bylo zamýšleno.

Správně by to mělo vypadat nějak takhle:

final class ErrorPresenter implements Nette\Application\IPresenter
{
	use Nette\SmartObject;

	public function __construct(
        private ILogger $logger,
    )
	{}

	public function run(Application\Request $request): Application\Response
	{
		$exception = $request->getParameter('exception');
        if ($exception instanceof BadRequestException) {
            $originalRequest = $request->getParameter('request');  // jdeme o jeden request v historii zpátky nette/web-project to nemá!!
			[$module, , $sep] = Helpers::splitName($originalRequest->getPresenterName());  // zde získáme modul, kde došlo k výjimce
            return new Responses\ForwardResponse($request->setPresenterName($module . $sep . 'Error4xx'));
		}
	.........
	}
}

Budu rád, když se k problematice ErrorPresenteru vyjádří další zkušení znalci Nette.

Když se vyhodí exception v error presenteru, tak to způsobí fallback na interní error presenter v Nette.

Nezpůsobí. Skončí to na interním error presenteru, co je přímo v Nette. Ten tvůj to znova nezkusí.

Editoval Marek Bartoš (5. 10. 2022 11:39)

Ještě připojuji poznámku k nette/web-project ErrorPresenteru – jak jsem výše psal, že je potřeba pro zjištění modulu ve kterém nastal upravit kód ErrorPresenteru a jít o jeden request v historii zpět, tak to není tak jednoduché. Záleží na tom, jak kde BadRequestException vznikne. Pokud ji vyhodí nějaký presenter aplikace, třeba na základě neexistence záznamu v databázi, tak moje oprava funguje. Ale BadRequestException může vyhodit i Router ještě předtím, než se presenter vytvoří a žádný request se nevytvoří. Potom máme v historii služby application.application jenom jeden request a sice ten s forwardovaným ErrorPresenterem. Potom můj kód nefunguje. Takže pokud by se to mělo takto použít, bylo by potřeba ještě ošetřit případ, kdy se request vůbec nevytvoří a zřejmě v tomto případě forwardovat na nějaký preferovaný modul.

@MarekBartoš Díky za trpělivost se mnou.