Don't reset existing password on request, prevent DoS password reset abuse - tja, genau das Problem hab ich auch bemerkt und konnte nicht fassen das tatsächlich jemand sowas in ein CMS eingebaut hat. Man kann in Drupal für einen Benutzer das Passwort wechseln - und zwar für jeden. Das neue Passwort wird dann diesem Benutzer per Mail zugeschickt. Man kann also darüber keinen illegalen Zugriff erlangen, ausser man kann die Mails des Benutzers abfangen (was in der Regel wohl hoffentlich nicht der Fall sein wird). Aber man kann einen Admin aussperren: einfach einen Job aufsetzen der minütlich das Passwort des Admins zurücksetzt. Und dann diese zwangsweise Abwesenheit des Admins dazu nutzen um das Drupal vollzuspammen zum Beispiel.
Sowas ist wirklich ein peinlicher Patzer. Wird leider viel zu gerne und viel zu häufig gemacht. Wer also Drupal betreibt, dem sei der Patch empfohlen (aufpassen, der Autor hat zwei Patches reingereicht, der erste war noch buggy). Liess sich problemlos installieren und behebt zumindestens die Aussperrung des Admins. Nervige Mails kriegt man natürlich trotzdem dabei.
Ganz eindeutig. Ich weiss nicht was es gegen mich hat, aber es hasst mich heute. Ganz massiv.
Ich hab mir das kubrick-Theme einfach unter einen eigenen Namen kopiert, damit ich es anpassen kann ohne das Kubrick-Theme selber zu ändern. Witzigerweise benutzt es jetzt aber nicht mehr die phptemplate-Engine. Oder genauer: der Eintrag in der Tabelle system (type='theme' und dann für das page.tpl.php) zeigt nicht auf phptemplate.engine, sondern auf phptemplate - das .engine fehlt. Wenn ich es per Update anhänge, funktioniert das genau ein mal. Danach wird dieser Eintrag in der Tabelle system überschrieben und .engine ist futsch und das Template kaputt. Mit Kubrick tuts das natürlich alles. Und natürlich findet man nirgendwo eine Info wo verflixt nochmal das Theme sagt welche Template-Engine benutzt werden soll - und wie dieser Eintrag in der Tabelle system entsteht. Nein, so einfach nach phptemplate.engine grepen bringt nix.
Ok, mir ist jetzt klar das die Engine die Einträge erzeugt - jedenfalls nachdem ich mir den Source zur Engine mal näher angeguckt habe. Da wird nach page.tpl.php gesucht und wenn das gefunden wird, wird mit der phptemplate.engine verbunden. Aber warum sollte die Engine ihren eigenen Namen falsch eintragen? Zumal sie es bei Kubrick ja richtig macht. Das hab ich ja auch einfach nur ausgepackt in das themes-Verzeichnis.
Jut, also weiter forschen. Ein grep -r auf INSERT in Kombination mit system findet dann im system.module die Funktion system_obtain theme info, in der diese Sätze geschrieben werden. Aber wie und wo genau da jetzt was damit gemacht wird - sorry, aber das findet man nicht raus ohne längeres Studium. Irgendwie wird das description Attribut mit einem Wert gefüllt der beim Kubrick-Theme mit .engine endet und bei allen anderen nicht. Kubrick referenziert die Theme-Engine exakt und korrekt, aber eine beliebig benamste Kopie von Kubrick mit identischem Inhalt referenziert eine Theme-Engine ohne .engine im Namen und tuts nicht. Toll. Aber Kubrick umbenennen funktioniert. Hä?
Ok, nächster Ansatz. Mein Template umbenennen in was anderes und Kubrick umbenennen in meinen eigentlich gewünschten Namen. Verwirrung komplett: mein Template tut nicht, aber das jetzt kubrick heissende und vorher nicht funktionierende tut jetzt auch nicht. Äh .. Also das Kubrick in was anderes umbenannt. Und mal mein zwischengelagertes ausprobiert. Das tuts jetzt. Unter einem Namen der nicht Kubrick ist. Hä? Hütchenspiel? Benenne jetzt die Themes so lange um bis ich irgendwann unter dem von mir gewünschten Namen ein funktionierendes habe und dann ist gut?
Also mal versucht das Hütchenspiel aufzulösen. Computer sind doch deterministische Kisten, das muss doch gehen. Ok, beide Templates (originales Kubrick und mein Hugo) umbenannt. In aa und bb. Und welches funktioniert? Das was bb heisst. Nochmal das ganze, nur jetzt die Rollen vertauscht. aa wird bbb und bb wird aaa. Welches funktionert jetzt? Das was "bbb" heisst. Wenn zwei phptemplate.engine basierte Themes im System installiert sind, funktioniert nur das zuletzt im System gefundene zum Zeitpunkt wo nach den Themes gesucht wird. Die anderen gehen kaputt.
Also muss ich jetzt erstmal rauskriegen was eigentlich mit den alten Themes los ist, warum die nicht zum Funktionieren zu kriegen sind. Erster Ansatz: einen Dump der Datenbank machen und mit grep gucken wo überall meine Freunde auftauchen. Dabei hab ich dann gleich gefunden was mit dem ominösen phptemplate ohne .engine ist: die entsprechenden Einträge enthalten statt des Punktes einen chr(0). Ascii-Null. Wird von MySQL zwar gespeichert, aber von PHP wohl abgeschnitten beim Zugriff. Und für die ganzen alten Templates sind diese ganzen kaputten Einträge da. Ausserdem hat sich noch die engine im Eintrag phptemplate extra templates in der Tabelle variable gemerkt welche Themes sie schon gesehen hat.
Noch mal ein clean room Test: die Einträge in der Tabelle system mit type='theme' und description like 'themes/engine/phptemplate%' rauswerfen. Dann weiss er nix mehr von den Themes und ihren Namen. Dann nur mein gewünschtes Template haben und dieses dann aktivieren. Und siehe da, es funktioniert auf Anhieb. Dann mal kubrick ausgepackt. Und es funktioniert. Danach tuts aber mein eigenes Theme nicht mehr. Wie erwartet - kubrick kommt im Alphabet nach hugo. Kubrick wieder löschen und schon tuts mein eigenes Theme wieder - nach entsprechendem Refresh.
Also nachforschen wo zum Kuckuck diese Geschichte passiert und wieso. Es passiert ja nur mit den phptemplate.engine Themes. Die xtemplate.engine Themes tuns ja problemlos. Wobei sich herausstellt das die es trotz des Bugs tun - er betrifft sie auch. Denn im system.module in system_theme data (wie ich das rausgefunden habe erspare ich den Lesern mal - es war einfach sukzessives Einsetzen von echo Befehlen um zu gucken wann wo was kaputt geht) wird im letzten Schritt - im Aufruf von system obtain theme info - an den Files das description-Element zerstört. Und das ist es, das in die Systemtabelle gespeichert wird um auf die Theme-Engine zu referenzieren. Nur das letzte Theme einer Engine behält den korrekten Eintrag, alle anderen sind kaputt.
Hmm. Der basename-Aufruf in Zeile 336 ist der einzige Kandidat - er liefert eigentlich nur die Theme-Engine ohne das .engine hinten dran raus. Aber er sollte das eigentliche Feld nicht verändern, deshalb hatte ich ihn vorher nicht sonderlich beachtet - die PHP-Doku sagt nix über Seiteneffekte dieser Funktion. Aber wenn ich den Eintrag auskommentiere, funktinioniert mein Theme und Kubrick auch - gleichzeitig. Im PHP Handbuch steht aber nix davon, das basename den ursprünglichen String verändert.
Also ein kleines Testscript geschrieben, das nur einen basename-Aufruf macht. Örks. Ja, das ist es - basename verändert den Ursprungsstring, und zwar haut es einen chr(0) anstelle des Punktes rein. Und siehe da, es gibt einen Bugreport aus 2002 dazu - ja, ich hab ne alte PHP 4.1.2 Version laufen, da Debian Stable. Beim Bugreport steht eine brauchbare Lösung für mein Problem - einfach die Variable in "" setzen und so mit String-Interpolation arbeiten. Und siehe da, Problem gelöst. Und Knoten ins Ohr machen: bei 4.1.2 macht basename die Quellvariable kaputt.
Und mit so einem Scheiss (damit mein ich den Bug, nicht Drupal) beschäftigt sich ein Programmierer beim Debugging
Ich hätte auch einen anständigen Job erlernen können. Whisky-Fass-Bewacher bei Jack-Daniels zum Beispiel ...
oder so könnte man zumindestens meinen. Heute im Programm: Drupal 4.5.2. Nettes Paket, gefällt mir vor allem weil es jetzt auch Kubrick als Theme für Drupal gibt und weil es recht mächtig ist und trotzdem noch einigermaßen überschaubar. Nur falle ich jedesmal wenn ich mich nach längerer Zeit wieder damit beschäftige auf die gleichen Sachen rein: zum Beispiel die Aktivierung von Übersetzungen. Ist ja toll das es Übersetzungen gibt. Aber wenn es nirgendwo auf der Website auch nur Andeutungen darauf gibt was man machen muss, dann sitzt man schon ziemlich doof da. Ok, ja, man muss nur das locale.module aktivieren. Und wo bitte steht das? In der x-ten Hierarchie im Administrationsmenü. Genauso toll: es wird eine Datenbankanbindung für PostgreSQL mitgeliefert. Dummerweise ist die aber erst ab PHP 4.3 brauchbar - ältere Versionen werden nicht unterstützt, obwohl Drupal ab 4.1 läuft. Nachdem ich alles umeditiert habe auf die alten Funktionsnamen liefs immer noch nicht: da fehlte scheinbar ein default für die Spalte uid in der Tabelle sessions. Nachdem ich das gesetzt hab, hängte sich das PHP auf beim Zugriff auf die Site. Ok, ja, ich weiss, MySQL nehmen (ich mag MySQL aber nicht ...). Fein, jetzt bin ich drin, ich hab auch Kubrick als Layout und deutsche Übersetzungen. Ok, einen Teil des Systems in Deutsch - da fehlen Berge von Strings. Also weiss ich was ich demnächst mal wieder machen werden. Toll. Genauso toll wie der Default-Wert für das Fileverzeichnis, der einfach nur "files" ist. Was nicht funktioniert wenn man Bilder upload für Benutzer erlauben will, weil dann "files" und "pictures" ohne / aneinandergehängt werden. Und nein, der / darf nicht vor "pictures" stehen, sondern muss hinter "files" stehen. Das bei Kubrick das Menü in der rechten Spalte bei der Aktivierung von Blöcken natürlich als "links" ausgewählt werden muss, brauche ich sicherlich nicht extra zu erwähnen. Und das das Handbuch alles andere als aktuell ist - sorry, aber das ist einfach lachhaft. Da wird noch von Verzeichnisstrukturen zum Teil gesprochen, die gibts garnicht mehr. Nein, die Einstellungen sind nicht in sites/default/settings.php - die sind in includes/conf.php.
Menno. Das ist so ein schönes Projekt. Und das ganze System ist wirklich leistungsfähig und stabil. Aber die Dokumentation ist wirklich ein Witz. Manchmal hab ich das Gefühl die Leute dokumentieren garnicht Drupal sondern irgendwas anderes
Schön ist es trotzdem, also will ich mal nicht zu laut meckern. Andere machens ja auch nicht wirklich besser. Trotzdem - könnte so schön sein, wenn der Hinweis auf das Online-Handbuch wirklich helfen statt verwirren würde ...