TYPO3 > RTE in TCA

In TYPO3 können Datensätze aus eigenen Extensions super leicht über das Backend bearbeitet und verwaltet werden. Hierzu wird das TCA verwendet, das alle Formularfelder der Datensätze genau spezifiziert. Die Dokumetation dazu auf typo3.org ist wirklich gut, aber es wird nirgendwo beschrieben wie man einen Richtexteditor (kurz RTE) darüber einbaut. Hier nun eine fertige Felder-Konfiguration dazu:

View Code PHP
$TCA['tx_extensionexample_domain_model_example'] = array(
	'columns' => array(
		[...]
		'description' => array(
			'exclude' => 1,
			'label' => 'Beschreibung',
			'defaultExtras' => 'richtext[*]',
			'config' => array(
				'type' => 'text',
				'eval' => 'required',
				'rows' => '5',
				'cols' => 48,
				'wizards' => array(
					'_PADDING' => 4,
					'RTE' => array(
						'notNewRecords' => 1,
						'RTEonly' => 1,
						'type' => 'script',
						'title' => 'LLL:EXT:cms/locallang_ttc.php:bodytext.W.RTE',
						'icon' => 'wizard_rte2.gif',
						'script' => 'wizard_rte.php'
					)
				)
			)
		),
		[...]
	)
);

Wichtig sind vorallem ‚defaultExtras‘ => ‚richtext[*]‘, und ‚wizards‘ => array([…]). Mit defaultExtras lassen sich außerdem noch einstellen welche Funktionen der RTE haben soll. In diesem Fall werden mit dem *Sternchen alle Funktionen freigeschaltet.

Sind Entwickler zu egoistisch?

Ja, die Frage ist ernst gemeint. Ich behaupte Entwickler denken während der Programmierung in erster Linie an sich selbst:

  • Sie schreiben den Code wartungsfreundlich, damit sie bei der nächsten Bearbeitung weniger Arbeit haben.
  • Sie schreiben möglichst modularen Code, damit das Programm später leichter erweiterbar bleibt.
  • Sie versuchen das Programm mit möglichst wenig Zeilen Code zu umzusetzen, um weniger schreiben zu müssen.
  • Sie schreiben automatisierte Tests, um nicht immer alles selbst testen zu müssen.
  • Sie schreiben Code (manchmal) Quick & Dirty, wenn sie keine Zeit oder Lust haben.
  • Sie bauen ein möglichst funktionales und einfaches User Interface, weil es schneller zu programmieren ist.
  • Sie dokumentieren den Code, damit man die Funktion später nachvollziehen kann.
  • …

Die Liste könnte man sicherlich noch weiterführen, aber so arbeitet der gemeine Programmierer. Was ich damit eigentlich aussagen will, der Entwickler denkt bei der Programmierung fast ausschließlich an sich selbst und gar nicht an diejenigen, die nachher das Programm benutzen sollen: Die Benutzer. Natürlich sind die oben genannten Punkte alle wichtig für die Programmierung, aber aus meiner Sicht sollte für den Entwickler an erster Stelle immer der Benutzer stehen und nicht der für den Programmierer beste Code. Erst wenn der Benutzer mit dem Programm wirklich zufrieden ist, kann die Software auch erfolgreich werden. WordPress beispielsweise ist sicherlich nicht wegen eines sauberen und modularen Codes so weit verbreitet, sondern weil es ein super benutzerfreundliches Backend hat, mit dem es einfach Spaß macht zu arbeiten.

Das ist mein kleiner Denkansatz für zukünftige Entwicklungen: Erst an den Benutzer denken und dann an den Code!

5 Gefahrenquellen in PHP-Anwendungen

PHP-Anwendungen sind bekannt dafür viele Sicherheitsmängel zu beinhalten (obwohl das nicht stimmt), trotzdem möchte ich heute einmal auf 5 der schwersten Sicherheitslücken aufmerksam machen. Schaut euch doch mal eure (älteren) PHP-Skripte an. Die meisten werden mindestens eine dieser 5 möglichen Gefahrenquellen wiederfinden 😉

  1. Daten, die aus der Datenbank kommen, sind sicher
    Grundsätzlich sollte auch die Datenbank als „Benutzer“ betrachtet werden und auch hier alle eingehenden Daten überprüft werden (z.B. wenn die Daten zur Generierung von neuen PHP-Code oder dem Laden von Dateien genutzt wird).
    Der Grund ist ganz einfach: Sollte ein Unbefugter Zugriff auf die Datenbank erlangen, könnte er damit evtl. auch direkt das Verhalten der PHP-Anwendung beeinflussen.
  2. Prepared Statements oder Escaping machen SQL-Injections unmöglich
    Über Best Practices gegen SQL-Injections habe ich bereits berichtet. Es reicht nicht aus nur Spaltenwerte mit Prepared Statements zu schützen. Auch Spalten-, Tabellennamen und alles was sonst noch vom Benutzer zur Datenbank gelangt, kann eine SQL-Injection enthalten.
  3. Session IDs, die in Cookies abgelegt sind, können nicht ausgelesen werden
    Das Standard-Verzeichnis für PHP-Sessions lässt sich von jedem, der ebenfalls einen Host auf dem Server hat, auslesen – ein Kinderspiel um an die IDs der Sessions zu gelangen. Verhindern lässt sich das am besten, in dem man ständig die IP-Adresse überprüft der Session abfragt, die Session-ID jedes mal gewechselt wird (session_regenerate_id()), oder man ein anderes Verzeichnis wählt (session_save_path()).
  4. Zugangsdaten zur Datenbank werden am sichersten in einer PHP-Datei abgelegt
    Die Aussage an sich ist natürlich völlig richtig, aber was passiert wenn die Datenbank plötzlich einen Fehler meldet und die Zugangsdaten über eine unglücklich programmierte Fehlerbehandlung zu Debugging-Zwecken ausgegeben wird?
  5. Mit MD5 verschlüsselte Passwörter sind sicher
    MD5-Hashes lassen sich mittlerweile kinderleicht über Hash-Datenbanken oder Rainbow-Tables knacken. Abhilfe schaffen Salted Passwörter oder verbesserte Verschlüsselungsmethoden wie beispielsweise RSA.

Nicht alle der fünf hier genannten Punkte sind selbstverständlich und manchmal denkt man auch nicht daran, dass so etwas ausgenutzt werden könnte. Daher macht es Sinn sich einmal selbst in die Rolle des Angreifers zu versetzten und zu versuchen seine eigene Anwendung mit allen Möglichkeiten zu hacken. Immerhin kennt man sich selbst mit seinem selbstgeschriebenen Code noch am besten aus.