Danke für die Aufklärung. Die GZIP-Komprimierung sollte keinen Einfluß auf das Bridging haben, sondern nur
Pfadangabe für Cookie:
Geben Sie hier einen relativen Pfad zur eigentlichen Domain, auf der sich Ihr Forum befindet, an. Eingestellt auf: /
Erklärung: diese im Englischen "cookie path" genannte Einstellung sollte in der Tat für 99% aller Benutzer nur "/" lauten. Das bedeutet im Klartext: WBB setzt einen Cookie, der dann nur von Seiten aufgerufen werden darf, die genau in diesem Verzeichnis liegen. Der "Slash" (Schrägstrich) steht dabei für "die gesamte Domäne ab dem Stammverzeichnis". Wenn also Dein Forum unter
http://deine_domain.tld/forum/ liegt und Deine Galerie unter
http://deine_domain.tld/galerie/, dann muss der Cookie-Pfad auf "/" gesetzt sein. Wenn Du ihn nämlich auf "/forum" setzen würdest, dann könnte Coppermine (das ja im obigen Beispiel im Verzeichnis "galerie" liegt) den Cookie nicht lesen.
Keine Regel ohne Ausnahme: auf den Seiten von (meist kostenlosen) Webhostern, die jedem Benutzer nur ein Unterverzeichnis zur Verfügung stellen (z.B.
http://kostenloser_webhost.de/dein_verzeichnisname/forum/ und
http://kostenloser_webhost.de/dein_verzeichnisname/galerie/, dann müsste der Cookie-Pfad auf "/dein_verzeichnisname" eingestellt werden, sonst könnte ja ein anderer Benuzer bei Deinem kostenlosen Webhost (z.B.
http://kostenloser_webhost.de/verzeichnisname_des_anderen_benutzers/) Deine Cookies auslesen.
Domainangabe für Cookie:
Hier können Sie angeben, unter welcher Domain die Cookies gespeichert werden sollen. Nichts Eingetragen!
Wie oben: für 99% aller Benutzer (nämlich alle, die eine eigene Domäne besitzen) ist der Eintrag von "nix" richtig.
Die berühmte Ausnahme: manche kostenlose Webhosts bieten Ihren Benutzern eine Sub-Domain an nach dem Schema
http://deine_sub-domain.kostenloser_webhost.de/. Um zu verhindern, dass
http://sub-domain_von_jemand_anderem.kostenloser_webhost.de/ Deine Cookies auslesen kann musst Du in einem solchen Fall die Cookie-Domäne auf ".deine_sub-domain.kostenloser_webhost.de" einstellen.
Präfix für Cookienamen:
Geben Sie hier einen optionalen Präfix für die Cookienamen an. Eingetragen: wbb2_
Hier ist nur zu beachten, dass der Präfix einheitlich in WBB und der Bridge sein muss. Beachtet außerdem, dass im Präfix die gleichen Regeln gelten wie für den Cookie-Namen selbst (den Euer BBS setzt): nur alphanumerische Zeichen, keine Umlaute, keine Sonderzeichen außer dem Unterstrich. Es ist empfehlenswert, nix an dem Präfix zu ändern.
Nochmal zur Verdeutlichung: das oben beschriebene ist nicht eine WBB- oder Coppermine-Eigenheit, sondern schlicht und ergreifend Cookie-Technologie. Nur so funktionieren Cookies. Es gibt keinen Grund, darüber zu motzen, da sich niemand darüber hinwegsetzen oder etwas daran ändern kann, genauso wenig wie man sich darüber beschweren kann, dass ein Feuer Wärme abgibt. Willst Du Feuer, dann wird es warm. Willst Du ein Skript einsetzen, dass Cookies benutzt, dann lebe mit der Technologie.
Abschlußbemerkung: wie oben beschrieben gibt es ein bißchen Wenn und Aber. Der Grund, warum WBB (genauso wie Coppermine) überhaupt die o.g. Einstellmöglichkeiten für Cookies anbietet ist: die Software soll so flexibel wie möglich gebaut werden, damit sie von einer Vielzahl von Benutzern in unterschiedlichen Umgebungen (eigene Domain, Sub-Domain beim Webhoster, Unterverzeichnis beim Webhoster) eingesetzt werden kann. Das ist ein Feature der Software.
Ne andere Frage, kann es sein, dass die Bridge ein Problem mit register_globals OFF hat?
Coppermine hat kein Problem mit
register_globals=off. Ich kann keine Aussage darüber machen, ob WBB damit ein Problem hat (am besten bei WBB nachfragen, wenn das ein Problem darstellt). Ich kann mir aber nicht vorstellen, dass das ein Problem ist: es ist empfohlen, dass alle Skripte ohne register_globals=on auskommen, da das einen Angriff ermöglichen würde (eine Frage der Sicherheit). WBB als kommerzielle Applikation benötigt höchstwahrscheinlich register_globals=on nicht.
Da die WBB-Bridge eine "user contribution" ist kann ich auch darüber keine Aussage treffen, kann mir aber nicht vorstellen, dass sie register_globals=on benötigt.