File resource URIs in FLUID unter TYPO3 6.x erzeugen (FAL)

Mit der Einführung von FAL hat sich auch das erstellen von Datei Resource Pfaden in FLUID Templates etwas verändert.

Mittels Image-ViewHelper läßt über das Attribut „treatIdAsReference“ einstellen, dass es sich um eine FAL-Datei-Referenz handelt:

Inline Syntax:
{f:uri.image(src:file,treatIdAsReference:1)}

Tag based Syntax:
<f:uri.image src=“{file}“ treatIdAsReference=“1″ />

Das Interessante:
Diese Methode funktoniert nicht nur für Bilder, sondern für alle Datei-Typen, die man z.B. als Download-Link anbieten möchte.

Ein weiterer Punkt der sich im Zuge der Recherche ergeben hat ist, dass man im „f:link.page“-ViewHelper im Attribut „pageUid“ nicht nur Seiten-IDs übergeben kann, sondern alle Werte, die auch der Typolink-Builder als Parameter entgegen nimmt.
Dadurch ist es möglich z.B. einen Datei-Download-Link in FLUID / FAL zu erzeugen:

<f:link.page pageUid=“{f:uri.image(src:file,treatIdAsReference:1)}“ target=“_blank“ />

Dieser wird dann auch durch den Typolink-Builder erzeugt, was den Vorteil hat, dass z.B. Extensions die sich dort einklinken funktionieren, z.B. um die Downloads abzusichern oder sprechende Links zu erzeugen.

Weitere Info: ImageViewhelper Referenz auf fedext.net

Powermail – XSS Problem mit Webkit Browsern

Bei Powermail (Version 1.6.9) gab es auf einer betreuten Seite ein Problem mit dem XXS Filter von Chrome/Safari.
Offenbar wird beim Versenden eines Formulars mit Powermail im Post Javascript mit versendet, das wiederum im Response auftaucht.
Die WebKit Browser werten das als mögliche XXS Attacke und der X-XXS-Filter greift und lässt das Laden sämlicher Resourcen auf der Bestätigungsseite nicht zu, was dazu führt, das eine zerschossene Bestätigungsseite nach erfolgreichem Absenden eines Powermail Formulars zu sehen ist…

Siehe auch:
http://stackoverflow.com/questions/1547884/refused-to-execute-a-javascript-script-source-code-of-script-found-within-reque

„This happens when some JavaScript code is sent to the server via an HTTP POST request, and the same code comes back via the HTTP response. If Chrome detects this situation, the script is refused to run, and you get the error message Refused to execute a JavaScript script. Source code of script found within request.“

Von hier wird auch hierauf verwiesen:
http://blog.chromium.org/2010/01/security-in-depth-new-security-features.html

„…
In the end nothing changes except that browsers are more complicated and fragile. Google serves its pages including this blog with X-XSS-Protection: 0 for a reason; that should tell you something.
…“

Also ist die „Lösung“ das Setzen eines zusätzlichen Headers, der den Filter unterbindet:
In TYPO3 sähe das so aus:
config.additionalHeaders = X-XSS-Protection: 0

TYPO3 – Seitenbaumrechte für Redakteure

Um zu erreichen, dass eine von einem Admin angelegte Seite von einem Redakteur zu sehen, zu bearbeiten und auch zu löschen ist, ist folgendes zu tun:

1) Zusätzlich zur Redakteursgruppe eine weitere Gruppe anlegen (z.B. Gruppe „Seitenbaumrechte“)
2) Alle Admins der Gruppe „Seitenbaumrechte“ zuordnen
3) Die Gruppe „Seitenbaumrechte“ als Untergruppe der Redakteursgruppe zuordnen

Wenn man das gleich beim Erstellen der Redakteursgruppe macht und dann auch die entsprechenden Rechte verteilt, dann muss man die folgende PAGE-TS cfg nicht mehr machen:

TYPO3.system-testen.de

Ein interessanter Blog zu Sicherheits-relevanten Themen in Bezug auf TYPO3 System von Tim Lochmüller unter:
http://TYPO3.system-testen.de

Besprochen wird bisher:
Mehr Code Qualität durch Dependency Injection in TYPO3 ExtBase / FLOW3
TYPO3 Sicherheit durch IDS
TYPO3 Core aktualisieren
TYPO3 Extensions aktualisieren
TYPO3 Sys Log prüfen