CSP im FrontendController, nonce immer null

[BugBuster]

Hi,
ich versuche an die "nonce" ranzukommen in meinem FrontendController (AbstractFrontendModuleController) für ein <script> Abschnitt im Template.
Dazu habe ich in der Startseite CSP aktiviert und als Policy angegeben:

default-src 'self' data:;
script-src 'self';
style-src 'self';

Im Controller habe ich das mit folgendem Code Schnippsel aus der Template Klasse probiert:

        $nonce = null;
        $responseContext = System::getContainer()->get('contao.routing.response_context_accessor')->getResponseContext();

        if ($responseContext?->has(CspHandler::class))
        {
            $csp = $responseContext->get(CspHandler::class);
            $nonce = $csp->getNonce('script-src');
        } 

Leider ist hier $nonce immer "null", weil die "if" Bedingung "false" ist.

Wie geht es richtig?

[Spooky]

Warum System::getContainer()?

Ist dein Controller ein ESI Fragment?

[BugBuster]

Warum System::getContainer()?

Ist dein Controller ein ESI Fragment?

1. Weil ich es wie gesagt erstmal aus der Template Klasse rauskopiert habe, da ich da nicht das ganze inline Script generieren lassen wollte sondern nur den nonce Anteil.
2. Ja, ein ESI Fragment. (renderer: esi)

[Spooky]

2. Ja, ein ESI Fragment. (renderer: esi)

Im Kontext eines ESI Requests steht dir kein Contao Response Context zur Verfügung, den gibt es nur im Main Request.

[BugBuster]

Na toll, wieder so ein Nachteil von Abstract Controller in Verbindung mit ESI.
Habe aufgehört zu zählen, auf wie viele Probleme ich damit schon gestoßen bin in den letzten Jahren.
Da hätte ich doch auf der alten Methode mit mehreren Insert-Tags bleiben sollen.

Damit ist dann Visitors teilweise nicht kompatibel mit CSP. Zum Glück bleiben die Basis Funktionen erhalten, da ohne JS.

[Spooky]

Warum lässt du überhaupt inline JavaScript via ESI ausgeben? Ändert sich das bei jedem Request oder unter anderen Bedingungen?

Generell gilt, dass man, wenn man CSP nutzen möchte, inline Styles und inline JavaScript vermeiden sollte. nonces sind ein Behelfsmittel, wenn es nicht anders geht.

[BugBuster]

Die Gesamte Ausgabe vom Visitors Frontend Modul ist ESI, da es sowohl die Zählung als auch gleich die Ausgaben macht, damit ich nur einen Request brauche, statt wie damals mit 10 Insert-Tags.
Es darf ja nicht gecached werden. Da bot sich bei der Umstellung eben ESI an.

Ich wüsste jetzt nicht wie ich das Aufteilen sollte. (Außer zwei FE Module dafür zu nutzen, eins ESI das andere nicht für den JS Anteil.)



Nebenbei, ich habe gesehen, das bei jedem Request sich das Nonce Hash ändert und an den entsprechenden Stellen in HTML dann eingetragen wird `<script ... nonce=...>'
Ist dann die Seite überhaupt noch cachebar?

[Spooky]

Warum darf das inline JavaScript nicht gecached werden? Muss es überhaupt inline sein?

Und ja, die Response ist cachebar, da ja die gesamte Response inkl. Header gecached wird.

[BugBuster]

Weil ich Teile vom JavaScript erstzen muss, die URL die Aufgerufen werden soll (Ajax), die ist bei jeder Seite anders.

[Spooky]

Weil ich Teile vom JavaScript erstzen muss, die URL die Aufgerufen werden soll (Ajax), die ist bei jeder Seite anders.

Und die kann nicht Client Seitig ermittelt werden?

[BugBuster]

nein, die URL hat 3 Paramater, die Kategorienummer des angelegten Zählers, die Page ID und ein Merker ob die Seite Protected ist oder nicht.
Ich lasse die komplette URL im Modul generieren und übergebe das mit an das Template und dort wird dann der Teil über die Variable ersetzt.

[Spooky]

Wenn es nur um Variablen geht, dann kannst du das ja per data Attributes ausgeben lassen.

Wie gesagt - wenn man CSP aktivieren möchte, sollte man inline JavaScript möglichst immer vermeiden.

[BugBuster]

Das wäre eine Idee, mal sehen wann ich Zeit dazu finde das mal auszutesten.

[BugBuster]

Die Kombination aus "nicht mehr inline" und Data Attributen sieht gut aus.
Noch ein wenig testen und es wir eine neue Version kommen.