EIDController und Middleware in TYPO3 9

EIDController - ich glaube jeder hat in einem etwas ambionierterem Projekt den Bedarf an dem besagten EIDController gehabt. Die Einbidung in das TYPO3 ist einfach, man definiert in seiner ext_localconf.php einfach die Klasse welche den EIDController darstellt.

$GLOBALS['TYPO3_CONF_VARS']['FE']['eID_include']['guengoeren'] = '\MyVendor\MyExtension\Controller\MyEidController::class' . '::myMethod';

Vor TYPO3 9 hat man dann in seinem EIDController im Idealfall einfach per EidUtility sich das TCA, Sprache oder einfach einen fe_user initialisiert. Schaut man sich die Helferklasse jedoch an, sieht man, dass diese für deprecated erklärt wurde. Das bedeutet kurz: In einer zukünfigten TYPO3 Version (in diesem Fall Version 10) wird diese komplett entfernt. Die Dokumentation empfiehlt hier, das man sein eID script zu einer PSR-15 middleware migiert und je nach Bedarf diese entsprechend positioniert.

Haben wir jetzt Fragezeichen über dem Kopf? Sehr gut! Einfach weiterlesen.

Middleware

Was sind PSR-15 middelwares, kurz: Das PSR-15 beschreibt eine Standard-Vorgehensweise zur Verarbeitung von Requests in einer Webanwendung. Letztendlich kann man sich das vereinfach so vorstellen: Der Request kommt rein durchläuft die definierten Middlewares und zum schluss gibts den altbekannten Response zurück. In der Java Welt nennt man das Ganze einfach Filter, Middleware wird diesem aber gerechter - meiner Meinung nach natürlich.

In der Middleware wird dann entschieden ob die Middleware den Request verarbeitet oder ihn einfach weiterschleift. Das Interface dafür ist recht einfach gehalten - keep it easy!.

namespace Psr\Http\Server;

use Psr\Http\Message\ResponseInterface;
use Psr\Http\Message\ServerRequestInterface;

/**
 * Participant in processing a server request and response.
 *
 * An HTTP middleware component participates in processing an HTTP message:
 * by acting on the request, generating the response, or forwarding the
 * request to a subsequent middleware and possibly acting on its response.
 */
interface MiddlewareInterface
{
    /**
     * Process an incoming server request.
     *
     * Processes an incoming server request in order to produce a response.
     * If unable to produce the response itself, it may delegate to the provided
     * request handler to do so.
     */
    public function process(ServerRequestInterface $request, RequestHandlerInterface $handler): ResponseInterface;
}

Ob eine Middleware den $request behandelt oder nicht kann an verschiedenen Punkten ausgemacht werden. Parameter, Header, etc.

Wie hilft uns das im TYPO3 weiter?

Es ermöglicht mehr flexibilität. Stand jetzt kann man seinen EIDController einfach wie gewohnt definieren, dieser wird dann vom \TYPO3\CMS\Frontend\Middleware\EidHandler verarbeitet. Das funktioniert super, wenn man zum Bsp. gar kein TCA/TSFE oder sonstiges braucht, doch was machen wir, wenn wir den Bedarf an einem vollem, korrekt initialisiertem TSFE haben? Wir schreiben eine Middleware. Wir brauchen nur die Datei RequestMiddleware.php unter Configuration anzulegen, in dieser definieren wir dann unsere Middlewares und vorallem, WANN diese greifen sollen.

<?php
return [
    'frontend' => [
        'my-ext-resolver' => [
            'target' => \My\Middleware\Resolver::class,
            'before' => [
                'typo3/cms-frontend/content-length-headers',
            ],
            'after' => [
                'yet-another-middleware-identifier',
            ],
        ]
    ]
];

Das sorgt dafür das unsere Middleware vor der Core Middleware typo3/cms-frontend/content-length-headers ausgeführt wird.

Alle im TYPO3 registrierten Middlewares können wir unter Configruation -> HTTP Middlewares (PSR-15) einsehen.

In meinem Beispiel würde die Middleware also aufjedenfall nach typo3/cms-frontend/prepare-tsfe-rendering greifen, d.h. ich habe in der Middleware ein volles TSFE zur Verfügung. Ganz ohne EidUtility oder sonstiges Hacks, wenn man in dem EIDController etwas mehr machen möchte - wie zum Beispiel Content rendern oder ähnliches.