ich spiele zur zeit ein wenig mit wordpress µ (auch: wordpress mu, kurz: WPMU). an sich ist es ja ein tolles teil. prima, um mehrere blogs unter einem dach zu verwalten. aber etwas stört mich grad gewaltig:

ich habe noch keine einfach möglichkeit gefunden, mehrere mysql-datenbanken zu nutzen. in der konfigurationsdatei gibt es zwar eine option, wo mensch eine unterstützung aktivieren kann, aber dann kommt auch sogleich immer nur ein fehler, wenn ich irgend ein blog aufrufen will.

ein großer nachteil, wenn mensch mal so eben einzelne wordpress blogs nach wpmu migrieren will und dabei weiterhin getrennte datenbanken benutzen möchte. und gerade, wenn mensch viele blogs hat, wird es ziemlich unübersichtlich mit den massen an einzelnen tabellen. das ist doof!

meine recherche hat wenig gebracht. darum meine frage an jene, die schon selbst mit wpmu experimentiert haben:

weiß jemand von euch, wie ich die multiple database-unterstützung korrekt nutze? deutsche und/oder englishe anleitungen dazu gern gewünscht. danke!

warum ich mich überhaupt dafür interessiere?

wie der geneigte besucher und leser feststellen kann, betreibe ich hier neben emblog noch weitere blogs, die zwar jetzt schon alle unter einem wordpress-kern laufen, aber eben das normale WP mit manueller unterstützung für subdomains und datenbanken. in vorbereitung eines tutorials wollte ich auch die vor- und nachteile von wordpress und wordpress mu aufzeigen. und ggf. auch verschiedene lösungsansätze bieten. dazu wäre es aber eben von nutzen, wenn ich wüsste, wie ich zB auch ordenliche migrationsanleitungen präsentieren kann für schon bestehende bloginstallationen. wenn ihr also etwas wisst und beitragen könnt: immer her damit! bei sehr guten hilfen von euch, werdet ihr auch mit namensnennung belohnt. ;o)

dank ondamaris wurde ich darauf aufmerksam gemacht, dass das wordpress-plugin “WP-Footnotes” in der version 2.2 eine sicherheitslücke aufweist.

das administrationspanel lässt sich ohne weiteres direkt aufrufen, wodurch schlupflöcher offen stehen (genaueren codingkram könnt ihr auf folgenden seiten nachlesen: http://securityvulns.com/Sdocument998.html [engl.], http://www.securityfocus.com/bid/27572/info [engl.]).

was ich interessant finde, ist die tatsache, dass eigentlich die lösung so simpel ist, dass sicherlich kaum einer daran denkt.

ich habe jedenfalls eine lösung gefunden, die das tut, was sie soll: den zugriff von außerhalb zu verhindern.

dabei kam mir zugute, dass selbst bei den standardthemes von wordpress eigentlich gewisse sicherheitsmaßnahmen ergriffen werden, die auch hierbei helfen.

betroffen ist ja die datei [wordpress]/wp-content/plugins/wp-footnotes/admin_panel.php.

diese datei muss nun geschützt werden, und zwar ganz einfach. folgender php-code am anfang der datei (vor oder nach dem ersten kommentarblock ist egal, ich habe es nach dem ganzen lizenzgesabbel eingefügt):

[sourcecode language='php'] if (’admin_panel.php’ == basename($_SERVER['SCRIPT_FILENAME']))

die (’Bitte diese Seite nicht direkt aufrufen. Danke!’);

?>[/sourcecode]

wer selbst schon mal themes bearbeitet hat, dem dürften diese vier zeilen code bekannt vorkommen. genau, sie sind zB in der comments.php des standardthemes zu finden (und sollten es aus sicherheitsgründen auch bei allen anderen themes sein).

was macht das da oben nun? joah, ganz einfach, wenn die aufgerufene URL im scriptnamen-bereich den gleichen namen hat, wie die admin_panel.php selbst (also sich selbst aufgerufen hat bzw. direkt aufgerufen wurde), dann verweigert das script seine weitere arbeit, indem es mit dem die-befehl sich verabschiedet.

im eigentlichen adminbereich von wordpress funktioniert das fußnoten-adminpanel weiterhin, weil es eben nicht direkt aufgerufen wird, sondern per include/require^[1] eingebunden wird, so dass der ursprüngliche scriptname eben nicht die modifizierte datei ist.

so sind wir nun alle wieder erst einmal glücklich, denn niemand vergreift sich von außen an der betroffenen und nun gesicherten datei, und wir können weiter fleißig fußnoten schreiben.

wer nicht selbst frickeln will, dem stelle ich hier meine wp-footnotes/admin_panel.php zur verfügung:

datei-link: admin_panel.phps [bitte mit "speichern unter..." sichern und die datei so umbenennen, dass die dateiendung von .phps auf .php lautet^[2] ]

ob in der zukünftigen version dieses loch von den entwicklern gestopft wird, weiß ich nicht, jedoch ist bei einem update darauf zu achten, dass es sicher ist, ansonsten sollte der obige code wieder eingefügt werden. sollte klappen.

und nun…^[3]

1. die methode habe ich nicht nachgeschaut, ist aber nich allzu relevant, es geht hier ums prinzip [↩]
2. ".phps" steht für php-source, somit kann php-quellcode veröffentlicht werden, da der webserver diese nicht verarbeitet, sondern als text anzeigt! [↩]
3. …fleißig weitere fußnoten schreiben! ;o) [↩]