Angehängte Session-ID an URLs unterdrücken

- sichtbar auch in Suchmaschinen
- verschwinden beim zweiten Aufruf


Aus JoomlaPortal


Bastelt mal eine Testdatei mit folgendem Inhalt oder kopiert das in die index.php des Templates zum debuggen:

php-Code: Test auf Session-ID
 echo "(". ini_get("session.use_trans_sid") .")";

die "Klammern" sollten leer sein oder die Zahl 0 enthalten, was eigentlich auch die Voreinstellung ist und der Sicherheit dient. Ist dies nicht der Fall, hat jemand daran geschraubt oder ihr habt 'ne verkorkste lokale "XAMPP"-Installation.
Ist der Wert "On", "true" oder "1" klebt PHP die Session-ID beim ersten Seitenaufruf kaputtautomatisch an die URL, an alles was nach einem Link riecht (href=xxx) und packt ein verstecktes Feld in *alle* Formulare. Genau: PHP verändert den HTML-Code bei dieser Einstellung eigenmächtig, nicht Joomla -- daher das zerschossene fieldset. Ab dem 2. Aufruf greifen i.d.R. die Cookies und die Session-ID "verschwindet" wieder auf magische Weise.

Um herauszufinden *was* PHP alles ändert kann man diese Zeile bemühen:

php-Code: Was PHP ändert
echo ini_get("url_rewriter.tags");

Zu dieser Einstellung sagt das Handbuch: "If you want XHTML conformity, remove the form entry." Hierzu sei aber auch gesagt, dass das Hinzufügen von "fieldset=" an diese Liste und zwar *nach* "form=" auch für Konformität sorgt.

Beides kann übrigens zur Laufzeit geändert werde, d.h. wenn PHP als Servermodul läuft (nicht der Fall bei 1und1 und vielen Pauschalhostern) in der .htaccess, ansonsten in einem Skript der möglichst gaaanz zu Anfang ein ini_set() enthält, d.h. "patchen".


Aus forum.joomla.org

Drei mögliche Lösungen wären:

1. Den folgenden Abschnitt in die session.php (/plugins/system/legacy/) einfügen:
 
php-Code: in /plugins/system/legacy/session.php einfügen
ini_set('session.use_cookies', '1');
ini_set('session.use_only_cookies', '1'); // PHP >= 4.3
ini_set('session.use_trans_sid', '0');
// Diese Zeile auskommentieren falls vorhanden:
// ini_set("url_rewriter.tags","a=href,area=href,frame=src,input=src,form=fakeentry");
ini_set('url_rewriter.tags', '');

oder 2.
in .htaccess einfügen
php_flag session.use_trans_sid off

Diese Zeile in die .htaccess-Datei einfügen. Das hat bei mir aber nur eine Fehlermeldung gegeben.


oder 3.
in eine php.ini ersetzen von
in php.ini ersetzen
session.use_trans_sid = 1
durch (oder einfügen wenn nichts vorhanden):
durch
session.use_trans_sid = 0

evtl. auch noch:
eventuell auch in php.ini
session.use_only_cookies = 1

 

Sämtliche php_xxx Angaben in einer .htaccess, httpd.conf oder sonstigen Apache-Konfigdateien funktionieren nur dann, wenn PHP als Servermodul installiert ist. Bei fast allen Hostern läuft PHP aber als "CGI", d.h. als externes Programm das von jedwelchen Einstellungen für Apache nix mitbekommt.


Vielleicht zur Klärung: wenn PHP Cookies für die Session-ID nehmen "darf" (soll) sind use_trans_sid und url_rewriter.tags irrelevant. Die sind der Notnagel, denn ohne Cookies kann PHP nur via URL-Anhängsel und Blindfelder in Formularen seine Session-ID "transportieren".
ini_set('session.use_only_cookies', 1) (ab 4.3) stellt zudem sicher, dass diese ID zwingend von einem Cookie kommen muss, d.h. selbst wenn eine gültige ID in URL oder FORM vorhanden wäre, wird sie ignoriert -- soll gegen Sessionklau schützen.
 

Über die robots.txt

 
Sollten oben genannte Wege nicht zum Ziel führen, gibt es noch die Möglichkeit den Suchmaschinen diese Information per robots.txt auf den Weg zu geben. Dazu sollte in die robots.txt folgender Eintrag aufgenommen werden:
 
Disallow: /*html?2165d7=*

Hiermit wird verhindert, dass die Suchmaschine alle die Dateien nicht liest, die auf der Domain mit einer beliebigen Anzahl von Zeichen beginnen, gefolgt von der festen Zeichenkette "html?2165d7=" dann wieder gefolgt von einer beliebigen Anzahl von Zeichen. Die Nummernfolge ist von Server zu Server unterschiedliche und in diesem Fall ein Schnipsel der Session-ID. Hier sollte man sich also anschauen wie die Session-ID aufgebaut werden und entsprechend einsetzen.

Zwar ist dieser komplexe String zuverlässig gegen Verwechslungen, so dass keine falschen Seiten ausgesperrt werden, aber das kann sich auf dem Server auch mal ändern. Entweder sollte man das regelmäßig prüfen, ob es noch Gültigkeit besitzt, oder einen String bauen, der weniger konkret ist. Evtl. reicht ja schon "/*html?*".