Chrome: Warnung vor unsicheren Ressourcen

Bildschirmfoto 2015-07-09 um 11.21.29Bei einer Website stießen wir kürzlich auf eine Warnung von Chrome (v 41), wie sie rechts zu sehen ist. Schnell war abgeklärt, dass keine „veraltete Kryptographie“ im Einsatz ist. Also nahmen wir den Teil „Diese Seite enthält jedoch andere, nicht sichere Ressourcen.“ unter die Lupe. Per Durchsicht im HTML-Quellcode konnten wir keine Resourcen-Einbindung mit „http://“-Quellen entdecken. Zur Sicherheit wurden sämtliche Javascripte und CSS-Dateien herausgenommen. Chrome meldete weiterhin seine Bedenken. Aus Clientsicht ließ sich nichts mehr erkennen. Wir guckten uns die Sache daher serverseitig an: welche Resourcen werden denn dort angefordert (nachdem wir externe Quellen ausschließen konnten)? Doch im access-Log tauchten zur Seiten-Anfragen via HTTPS auch nur Folgeanfragen via HTTPS auf. Nach und nach haben wir die Seite weiter minimalisiert – bis der „Schuldige“ gefunden war: ein Formular, das als action-URL einen http-URL enthielt.

Merke:
action-URLs sind zwar keine Resourcen, werden von Chrome aber offenbar als solche angesehen und ggf. bemängelt.

Danke für diese doch so aussagekräftige Fehlermeldung… 🙁

Standard-Mailform

Minimales Setup für Standard-Mailformular sollte mitbringen:

  • Reply-To an Websitebesucher
  • fester From-Name…
  • …und From-Email (sonst ggf. falsch automatisiert ermittelt)

Konfiguration könnte somit etwa aussehen wie folgt:

 Name | *replyto_name=input
 E-Mail | *replyto_email=input
 Nachricht | *Nachricht=textarea
 
 | from_name=hidden | example.com
 | from_email=hidden | info@example.com
 | formtype_mail=submit | Absenden
 | html_enabled=hidden
 | subject=hidden | example.com Mailformular

Mit getText in generischen Markern auf tt_content zugreifen

Heute benötigte ich innerhalb eines generischen Markers von tt_news Zugriff auf das Content-Element, in dem die Meldung angezeigt wird (also die Plugin-Einbindung). Warum man sowas braucht? Naja, Projekte entwickeln sich manchmal kreativ… 😉

Generische Marker werden im Zuge des Renderings der einzelnen Newsmeldungen ausgewertet, d.h. der Zugriff über field etc. ist jeweils auf den tt_news-Datensatz, nicht auf das Inhaltselement. Der Datensatz selbst hat auch keine Verknüpfung zum Inhaltselement. 🙁

Die Kollegen der marit.ag haben vor Längerem den Artikel „Datenbankfelder dynamisch per stdWrap.data auslesen“ verfasst. Damit ließe sich (via „getText“) auf beliebige Datensätze dynamisch zugreifen wie folgt:

genericmarkers {
        ceheader >
        ceheader = TEXT
        ceheader {
            // @see http://blog.marit.ag/2009/12/15/datenbankfelder-stdwrap-data/
            dataWrap = DB:tt_content:{field:pid}:header
            wrap3 = {|}
            insertData=1
        }
}

Es bleibt aber die Problematik, dass wir die uid des tt_content-Datensatzes dennoch nicht kennen. Hilfe bringt aber der Inhalt von TSFE: dort gibt es einen Wert currentRecord:

This is set to the [table]:[uid] of the record delivered in the $data-array

Somit lässt sich der Ansatz erweitern, indem im dataWrap der Teilstring „[table]:[uid]“ dynamisch ersetzt wird:

genericmarkers {
        ceheader >
        ceheader = TEXT
        ceheader {
            // @see http://blog.marit.ag/2009/12/15/datenbankfelder-stdwrap-data/
            //dataWrap = DB:tt_content:{cObj:TSFE:parentRecordNumber}:header
            // {TSFE:currentRecord} liefert etwas in der Art "tt_content:1234"
            dataWrap = DB:{TSFE:currentRecord}:header
            wrap3 = {|}
            insertData=1
        }
}

Quellen

Suggest-Wizard mit PAGE_TSCONFIG_*-Werten

Wird bei Relationen die Auswahl (zu) groß, ist oftmals die Einschränkung via TCA und PAGE_TSCONFIG_*-Werten in den addWhere-Klauseln sinnvoll. Zusammen mit dem Suggest-Wizard wäre damit die Datenmenge für den Redakteur handhabbar. Leider stoßen wir hier aber auf ein Problem, wie Frank im Kommentar zu Steffen Blogartikel „Using the new TCA wizard „suggest“ for autocompletion in BE fields of TYPO3 4.3“ schon anmerkt:

Just found out, that suggest doesn’t work with „foreign_table_where“-conditions with markers like „###PAGE_TSCONFIG_IDLIST###“. Only the explicit csv-list works in that case.

Aber warum? Schaut man sich die Klasse t3lib_TCEforms_Suggest an, so sieht man, dass lediglich zwei Marker ersetzt werden: THIS_UID, CURRENT_PID. Mit einer einfachen Änderung ließe sich dies ergänzen um die PAGE_TSCONFIG_*-Werte. Gibt es einen Grund, weshalb das seit TYPO3 4.3 noch niemand gemacht hat?

Workaround

Ersetzen dieser Codezeilen der Klasse t3lib_TCEforms_Suggest

if (isset($config['addWhere'])) {
	$config['addWhere'] = strtr(
		' ' . $config['addWhere'],
		array(
			'###THIS_UID###' => intval($uid),
			'###CURRENT_PID###' => intval($pageId),
		)
	);
}

durch

if (isset($config['addWhere'])) {
	$config['addWhere'] = strtr(' ' . $config['addWhere'], 
		array(
			'###THIS_UID###' => intval($uid),
			'###CURRENT_PID###' => intval($pageId),
			'###PAGE_TSCONFIG_ID###' => intval($TSconfig['TCEFORM.'][$table . '.'][$field . '.']['PAGE_TSCONFIG_ID']),
			'###PAGE_TSCONFIG_IDLIST###' => $GLOBALS['TYPO3_DB']->cleanIntList($TSconfig['TCEFORM.'][$table . '.'][$field . '.']['PAGE_TSCONFIG_IDLIST']),
			'###PAGE_TSCONFIG_STR###' => $GLOBALS['TYPO3_DB']->quoteStr($TSconfig['TCEFORM.'][$table . '.'][$field . '.']['PAGE_TSCONFIG_STR'], $fieldConfig['foreign_table']), 
		)
	);
}

Update

Ein Feature-Request wurde inzwischen erstellt und ein Patch eingereicht. Dieser darf gerne einem Review unterzogen werden 🙂

Links

realURL: optimierte Multi-Domain-Konfiguration

Ausgangssituation

In einem Projekt waren in einer TYPO3-Instanz über den Seitenbaum mehrere Marken in verschiedenen Ländern mit jeweils eigenen (Teil-)Seitenbaum abgebildet. Die einzelnen Websites waren inhaltlich-strukturell sehr ähnlich, und es waren viele spezifische Plugins im Einsatz. Insgesamt entstand so für die rund 100 Einstiegseiten eine (via realURL-Autoconfiguration erzeugte) rund 4,5 MB große Konfiguration. Die war uns ein Dorn im Auge.

Weiterlesen»