INSTALL_AUTODETECT_URL und INSTALL_URL für Trackbacks pp.

[thh]

Moin!

Soweit ich sehe, generiert Serendipity Links pp. via baseURL aus der Einstellung INSTALL_URL oder, wenn die INSTALL_AUTODETECT_URL auf "true" gesetzt ist, aus Hostnamen und Protokoll, mit dem es aufgerufen wird. Das funktioniert grundsätzlich gut.

Mir ist allerdings aufgefallen, dass s9y die per INSTALL_AUTODETECT_URL automatisch erkannte URL auch für Trackbags, Ankündigungen via Twitter, die für das Exit-Tracking generierten Links usw. verwendet, also auch diese ggf. mit dem Hostnamen generiert, der für den Aufruf von s9y verwendet wird. Das gefällt mir nicht so gut; ich würde mir wünschen, dass für alle diese Funktionen stattdessen immer die als INSTALL_URL angegebene Stamm-URL verwendet wird (oder das Verhalten konfigurierbar ist, wenn es Nutzer gibt, die das bisherige Verhalten vorziehen).

Der Grund dafür ist, dass ich INSTALL_AUTODETECT_URL verwende, um mein Blog (bzw. dessen Backend) via HTTPS aufrufen zu können. Siehe dazu http://board.s9y.org/viewtopic.php?p=10439619#p10439619, wo onli diesen Tip gab. Weil mein Zertifikat nur selbstsigniert ist und daher ggf. Browserwarnungen bei Besuchern generiert, möchte ich aber keine HTTPS-URLs in Trackbacks, Twitter-Ankündigungen pp. sehen, sondern die als INSTALL_URL angegebene Stamm-URL mit HTTP (ohne S).

M.E. ist das für jedes Blog, das unter mehreren Hostnamen aufgerufen werden kann, das sinnvollste Verhalten, weil es idR einen "generischen" Namen haben wird und es sinnvoll erscheint, alle Trackbacks pp. immer mit derselben URL auszusenden und das nicht vom Zufall des Aufrufs des Backends abhängig zu machen.

(Ich hoffe, ich konnte verständlich artikulieren, was ich meine. )

Grüße,
-thh

[onli]

Eine erste Anmerkung: Wir hatten in Serendipity 1.7 einen ziemlich unhübschen Bug mit diesen Optionen, der Autodetection und der manuellen URL, den wir viel zu spät bemerkt haben. Vll bedeutet gerade das, dass man sich den Bereich nochmal anschauen sollte, aber man muss da ein bisschen vorsichtig sein und ich lasse da lieber die Finger von.

Ich möchte dir vorschlagen, mit startssl lieber ein browserkonformes kostenloses Zertifikat anzulegen, als hier auf Abhilfe zu hoffen. Außer natürlich, einer der anderen - Garvin insbesondere - möchte das angehen.

[garvinhicking]

Den Wunsch danach kann ich gut nachvollziehen. Praktisch ist es nur leider so dass baseURL an allen möglichen Stellen im Code genutzt wird. Man müsste eigentlich JEDE Stelle einzeln prüfen und dann entscheiden, ob dort besser das automatisch erkannte baseURL stehen sollte, oder das fest konfigurierte "kanonische".

Das ist potentiell arg fehleranfällig, und ein Heidenaufwand. Ich traue mich da ehrlich gesagt zum jetzigen Zeitpunkt nicht dran.

Falls Du jetzt aber schon 2-3 konkrete Stellen im Code gesehen hast, wo die automatisch erkannte baseURL nicht richtig ist, und stattdessen die defaultURL erscheinen sollte, dann könnte man das schon gerne mittelfristig in den Code einfügen. Für die 2.0 würde ich diese Kanne ungerne öffnen, aber für eine 2.1 wäre so ein Pull Request oder Patch schon ganz schön.

Man könnte es ggf. sogar so vorbereiten dass man eine neue Option

$serendipity['enforceCanonical'] = true;

in der serendipity_config_local.inc.php setzt, und dann in den Stellen z.b. für Trackback-URLs auf diese Variable prüft, wenn sie da ist nutzt man die defaultBaseURL und ansonsten die baseURL. So hätte man den Code schonmal vorbereitet, und willige USer wie Du könnten es bei sich aktivieren um schonmal zu testen...

VG,
Garvin

[thh]

Eine erste Anmerkung: Wir hatten in Serendipity 1.7 einen ziemlich unhübschen Bug mit diesen Optionen, der Autodetection und der manuellen URL, den wir viel zu spät bemerkt haben.

An so etwas in der Art erinnere ich mich dumpf und dunkel, ja.

Ich möchte dir vorschlagen, mit startssl lieber ein browserkonformes kostenloses Zertifikat anzulegen, als hier auf Abhilfe zu hoffen.

Wenn das so einfach wäre, hätte ich das schon gemacht.

(Viele Domains, eine IP, Subject Alternate Names, bei denen ab und an einer dazukommt. Das gibt es AFAIS nicht preisgünstig von einer CA.)

Grüße,
-thh

[thh]

Den Wunsch danach kann ich gut nachvollziehen. Praktisch ist es nur leider so dass baseURL an allen möglichen Stellen im Code genutzt wird. Man müsste eigentlich JEDE Stelle einzeln prüfen und dann entscheiden, ob dort besser das automatisch erkannte baseURL stehen sollte, oder das fest konfigurierte "kanonische".

Das ist potentiell arg fehleranfällig, und ein Heidenaufwand. Ich traue mich da ehrlich gesagt zum jetzigen Zeitpunkt nicht dran.

Nachvollziehbar. - Ich denke auch, dass die 2.0-Version jetzt erste Priorität haben sollte.

Falls Du jetzt aber schon 2-3 konkrete Stellen im Code gesehen hast, wo die automatisch erkannte baseURL nicht richtig ist, und stattdessen die defaultURL erscheinen sollte, dann könnte man das schon gerne mittelfristig in den Code einfügen. Für die 2.0 würde ich diese Kanne ungerne öffnen, aber für eine 2.1 wäre so ein Pull Request oder Patch schon ganz schön.

Dann packe ich das mal auf die - lange - Liste der Dinge, die ich bei ausreichender Freizeit einmal angehen will.

Man könnte es ggf. sogar so vorbereiten dass man eine neue Option

$serendipity['enforceCanonical'] = true;

in der serendipity_config_local.inc.php setzt, und dann in den Stellen z.b. für Trackback-URLs auf diese Variable prüft, wenn sie da ist nutzt man die defaultBaseURL und ansonsten die baseURL. So hätte man den Code schonmal vorbereitet, und willige USer wie Du könnten es bei sich aktivieren um schonmal zu testen...

Würdest Du das generell für etwas halten, das man optional (de-)aktivieren kann, oder würde auch die (einfachere) generelle Anpassung an den richtigen Stellen ein gangbarer Weg sein? Will sagen: braucht man eine Weiche der Art "enforceCanonical"?

Grüße,
-thh

[garvinhicking]

Hi!

Würdest Du das generell für etwas halten, das man optional (de-)aktivieren kann, oder würde auch die (einfachere) generelle Anpassung an den richtigen Stellen ein gangbarer Weg sein? Will sagen: braucht man eine Weiche der Art "enforceCanonical"?

Letztlich ist das Zeil natürlich, die Weiche nicht mehr zu brauchen. Ich würde dies erstmal nur vorsehen um den Code so zu halten dass er für Bestandsnutzer keine Probleme bringt, und nur gezielt aktiv wird. Sobald das erstmal in einer begrenzten Runde gut läuft und sich in 1-2 Release bewährt, würde ich die Weiche killen und es pauschal aktivieren, da ich auch denke dass das nur Vorteile bringt.

LG,
Garvin