This is a collection of BugReports in .de language. Dies ist die deutschprachige Variante der Seite "BugReports".

HTTPS Support in ErfurtWiki

Per default rechnet die ewiki_script_url() nur fuer http:// gueltige URLs aus. Wenn man das Wiki aber ueber HTTPS laufen lassen will, nuetzen die einem nix.

Quick Fix in ewiki.php ab line 889:

if (array_key_exists("HTTPS", $_SERVER) && $_SERVER("HTTPS") == 'on') {
$urlPrefix = "https://";
} else {
$urlPrefix = "http://";
}

$url = $urlPrefix . $_SERVER("SERVER_NAME") . $url; return($url);

NOTE: Die runden Klammmern bei _SERVER() sollen natuerlich eigentlich eckige sein, aber dann wirds ja gleich nen link.. kann man bestimmt irgendwie escapen, weiss nur nicht wie :)

milky: Den Fix haben wir inzwischen im CVS - es gab nur in letzter Zeit keine neuen Releases. Trotzdem, tnx. Und [Escapen] funktioniert mit dem Ausrufezeichen, und in PHP funktionierte bisher auch $_SERVER{"HTTPS"} wie in Perl.


Kommentare

Bei mir funktionieren die Kommentare nicht mehr, in Version 1.01c ging es, glaube ich, noch.

Edit: hier jetzt doch, in der SandBox hier ging es eben auch nicht... ?(

Edit2: ah, verstehem sie müssen jetzt halt mit - - > geschlossen werden, dann geht's auch. Hat sich dann erledigt.

Gruß, Halvar

milky: Ja, da bin ich selber schon drauf reingefallen! Die Syntax hat sich wirklich geändert; hätte nur mal richtig dokumentiert werden müssen (Ooops). - Inzwischen find ich die Kommentare aber besser so. Mit ein wenig Trickserei kann man aber auch die alte Variante wiederbekommen (eine reine Einstellungssache).


trans_sid

Das Wiki funktioniert nicht zusammen mit session.use_trans_sid=1, da in einigen Redirects (Header: Location) die SID nicht mitgeschleift wird. Daher ist das Script praktisch nicht innerhalb Session-basierter Systeme einsetzbar. Der Fix ist trivial. Die Konstante "SID" ist immer dann definiert, wenn keine Cookies zur Verfügung stehen und muss nur an sämtliche URLs, die über Header- oder Meta- Weiterleitung aufgerufen werden, angehängt werden.

milky: Na ja, zur Not kann man das mit reinbauen - aber ich denke das sollte eher in PHP korrigiert werden (zumindest für die Apache-libphp-Version sollte das gehen, der CGI-Interpreter ist sicher zu kaputt dafür).

Naja, PHP hat da eigentlich nix zu korrigieren, ist ja kein Bug... Die Sessions funktionieren bei normalen Links oder Get/Post Formularen automatisch, bei allem anderen (Also Header-Weiterleitung, Meta-Tag Weiterleitung sowie Javascript) muss man's selber machen.

milky: Aber wenn PHP schhon die HTML-Ausgaben modifiziert, dürften ein paar header (Location:, URI: und Refresh:) ja im Prinzip auch kein Problem sein.

Das Problem mit diesem Fehler ist, dass er den meissten garnicht auffallen wird. Ich vermute eigentlich, dass ewiki sehr häufig zusammen mit Sessions benutzt wird. Aber wenn der Programmierer nicht explizit mit ausgeschalteten Cookies testet, kommt der Fehler halt nie zum Vorschein.

Es gibt übrigens einen zweiten Fehler mit Sessions. Beispielsweise hab ich eine Datei "wiki.php", die Dein Script einbindet... Mit angehänger Session-Variable rufe ich folgendes auf:

wiki.php?PHPSESSID=4d85...

Daraufhin zeigt Dein Script statt der Startseite aber nun plötzlich eine Seite mit dem Namen "PHPSESSID=4d85..." an.

Auch hier sollte der Fix trivial sein.

milky: Das ist ein Feature, das URLs wie index.php?*WikiSeite (statt index.php?id=*WikiSeite) erlaubt. Läßt sich aber bestimmt auskommentieren - zur Not könntest du aber auch URLs wie wiki.php?id=&PHPSESSID=... verwenden.

Diese komischen Session-URLs find ich jetzt auf jeden Fall total bescheuert, drum werd' ich das xsess-modul (server-seitige sessions, finger-print statt cookies) doch mal in einem der nächsten releases beisteuern.

Eine andere Lösung für dieses URL-Problem wäre übrigens die Weiterleitungen komplett abzuschalten "define('EWIKI_HTTP', 0);" - unelegant, aber möglich.

milky: So, die CVS-Version enthält jetzt den entsprechenden Fix (ist auch bereits im letzten Snapshot).

bottom corner