Code Styling Project

In letzter Zeit bekam ich immer mal wieder Anfragen, wieso mein Übersetzungsplugin CodeStyling Localization nicht mit IDN Blogs funktioniert. Zuerst einmal habe ich mit verschiedenen Tests nichts finden können. Es hat Stunden gebraucht um zu erkennen, dass es sowohl vom Browser als auch von WordPress abhängt. Aber woher kommt denn dieses Problem nun? Wenn man tiefer eintaucht, findet man dann schliesslich die Wurzel des Übels. Es ist sehr interessant, dass es sich um ein Problem für Cross Site Scripting und Browser Sicherheit dreht.

Der Grund der funktionsgestörten JSON Anfragen

Das Problem entsteht dadurch, dass Browser prüfen, ob eine AJAX Anfrage eine Domain aufruft, die nichts mit der Domain zu tun hat, aus der das Script bzw. die HTML Seite stammt. Das betrifft genauso Subdomains. Bekannt ist dies auch unter “same origin policy”. Erkennt der Browser eine solche Diskrepanz, dann verweigert er die Ausführung von JSON Ergebnissen und stellt diese nur als responseText statt responseJSON bereit. Wenn das eigentliche Script aber JSON Javascript Objekte erwartet, kommt es nun zu einem Scriptfehler, der dann die Funktion beeinträchtigt oder einstellt.

Warum passiert das ausgerechnet auf IDN basierten Blogs?

IDN Blogs werden normalerweise mit der PunyCode Notation konfiguriert. Um es besser zu verstehen, hier mal ein Beispiel eines Nutzers, der dieses Problem an mich rangetragen hat:

• IDN URL: http://с-проект.рф
• PunyCode URL: http://xn—-jtbpoegeo.xn--p1ai

WordPress selbst generiert die admin ajax url wie konfiguriert, also als PunyCode. Der Browser zeigt dennoch den internationalen Link in der URL Zeile an. Nun zum Problem: Für einige Browser ist der IDN Name nicht das Gleiche wie der dazugehörige PunyCode Name! Wenn man nun eine Ajax Anfrage schickt, die JSON zurückliefern soll, erkennt der Browser den Unterschied zwischen IDN und PunyCode und stuft das als Cross Site Scripting ein und unterdrückt die JSON Interpretation.
Randnotiz: In den meisten Fällen ist diese “same origin policy” auch der Grund, weshalb einige Flash Objekte in der Seite nichts mehr machen in IDN Umgebungen (zu Beispiel auch der Flash Uploader).

Welche Browser sind betroffen?

Der WordPress Core stellt, wie bereits erwähnt, die Admin Url für Plugins und/oder Themes und deren potentiellen AJAX Aufrufen als PunyCode zu Verfügung. Diese PunyCode basierte Admin Url funktioniert wie erwartet in folgenden Browsern:

• Google Chrome
• Safari (Windows)

aber es geht völlig schief in getesteten Browsern wie:

• IE
• Firefox
• Opera

Es hat einige Zeit gebraucht, dafür eine Umgehung zu finden. Werfen wir mal als Nächstes einen Blick drauf, wie man das machen kann.

aktuelle Lösung für mein Plugin

Mein Plugin nutzt einen eigene Konstante für die von WordPress bereitgestellte Admin Url. Trotzdem basiert die Definition dieser Konstante auf den vom WordPress Core bereitgestellten Funktionen. Nun habe ich zusätzlich eine einfache Browser Erkennung hinzugefügt und erstelle diese Konstante bedingungsabhängig.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

	//Bugfix: ensure valid JSON requests at IDN locations!
	//Attention: Google Chrome and Safari behave in different way (shared WebKit issue or all other are wrong?)!
	if (stripos($_SERVER['HTTP_USER_AGENT'], 'chrome') !== false || stripos($_SERVER['HTTP_USER_AGENT'], 'safari') !== false) {
		if (function_exists("admin_url")) {
			define('CSP_PO_ADMIN_URL', rtrim(admin_url(), '/'));
		}else{
			define('CSP_PO_ADMIN_URL', rtrim(get_option('siteurl').'/wp-admin/', '/'));
		}
	}
	else{
		if (!class_exists('idna_convert'))
			require_once('includes/idna_convert.class.php');
		$idn = new idna_convert();
		if (function_exists("admin_url")) {
			define('CSP_PO_ADMIN_URL', $idn->decode(rtrim(admin_url(), '/')), 'utf8');
		}else{
			define('CSP_PO_ADMIN_URL', $idn->decode(rtrim(get_option('siteurl').'/wp-admin/', '/'),'utf8'));
		}
	}

Wenn der Browser kein Safari oder Chrome ist, wird nun erstmal geprüft, ob einen IDN Konverterklasse existiert, die das wieder von PunyCode in UTF8 IDN zurückdrehen kann. Wenn diese Klasse existiert, benutze ich sie einfach (wie es übrigens auch SimplePie tut) oder lade sie eben selbst nach.
Die Klasse wurde nicht von mir entwickelt, deshalb hier die Daten des Autors.

1
2
3

 * @author  Matthias Sommerfeld <mso@phlylabs.de>
 * @copyright 2004-2011 phlyLabs Berlin, http://phlylabs.de
 * @version 0.8.0 2011-03-11

Ich habe diese Datei meinem Plugin zugefügt. Mit dieser bedingten “Umkodierung” der Admin Url arbeitet es nun perfekt mit IDN und normalen Blogs.

Zusammenfassung: Bug oder Feature?

Ich bin mir nicht sicher, ob dies nun ein Bug oder ein Feature ist. Meiner Meinung nach sollten sich alle Browser gleich verhalten, was IDN Urls angeht, tun sie aber nicht. Beide Darstellungen (PunyCode und IDN) sollten für die Browser identisch sein, sind es aber nicht. Da es diese Diskrepanzen in den Browsers gibt, würde ich erwarten, dass der WordPress Core darauf Rücksicht nimmt, tut er aber auch nicht!
Ich richte hier nicht darüber, wer es falsch oder richtig macht. Allerdings sollten sich die Browser Hersteller einigen und auch WordPress sollte wenigstens Vorkehrungen für solche Fälle an Bord haben, damit man nicht immer wieder in solche Fallen tappt und endlose Support Orgien fahren muß.