session.use_trans_sid bei abgeschalteten Cookies
Eingetragen von heinz963 (20)am 18.03.2009 - 18:11 Uhr in
Hallo zusammen,
mal schauen ob mir einer weiter helfen kann und möchte. Ich müsste mit Session Variablen arbeiten, die ich, wenn keine Cookies erlaubt sind, über die URL weitergeben wollte. Dachte kein Problem, schließlich gibt es dafür in der settings.php ja extra einen Eintrag. Aber von wegen, macht keinen Unterschied ob da bei session.use_trans_sid 0 oder 1 eingetragen ist. Ich hab das vorsichtshalber auch mit einer neuen Installation überprüft. Die settings.php editiert und anschließend in der page.tpl.php die sid ausgegeben. Wie erwartet, nach jedem Refresh eine neue sid. Die nachfolgenden Recherchen im Forum brachten dann zu Tage dass session.use_trans_sid bei abgeschalteten Cookies ab Version 4.7 wegen Robots und voll geschriebener SessionTabellen nicht mehr unterstütz wird.
Ich habe dann weitergeschaut, weil es doch einige Einträge zur Problematik gab. Unter anderem einen Patch, der wohl mit Drupal 6.3 noch funktioniert hat, den ich aber in die Version 6.8, nicht übernehmen konnte. Dort wird auch die Funktion function sess_write aus der session.inc gepatcht, aber die Zeilen die der Patch entfernen soll, gibt es nicht mehr in der Funktion. Die Funktion ist sehr übersichtlich und es geht wohl auch nur darum an einer Stelle trotzdem in die Tabelle zu schreiben. Sieht nicht sehr kompliziert aus, aber übersteigt meine Kenntnisse. Ich würde mich deshalb freuen, wenn sich die Cracks unter Euch das mal anschauen. Ich denke der Aufwand ist nicht groß und es würde vermutlich nicht nur mir damit geholfen werden.
Nun noch der Link zu dem Thread und Patch:
http://drupal.org/node/58019
in dem Thread ist die Message 13 entscheidend, mit dem Patch http://drupal.org/files/issues/nocookies.patch
Vielen Dank schon im voraus
- Anmelden oder Registrieren um Kommentare zu schreiben
Session ohne Cookies
am 10.05.2009 - 10:38 Uhr
Olà zusammen. Ich bereite aktuell die Migration eines wichtigen Projektes weg von einem selbstentwickelten Framework hin zu Drupal vor. Mein bisheriges System ist in der Lage, zu erkennen, ob Cookies akzeptiert werden oder nicht und es stattet, falls nicht, alle Links, Formulare etc. mit einer Sessionid aus, die je nachdem per POST oder per GET weitergereicht wird.
Diese Funktionalität ist absolut entscheidend für einen Umstieg. Sessionklau unterbinde ich durch komplettes Linkfiltern über eine Redirectseite (nur damit sich niemand bemüßigt fühlt, mir zu erklären, daß "man das nicht macht").
Daher meine Fragen als Neuling, nachdem Google-Recherchen mich auch nur bis zu dem vom OP genannten Patch geführt haben, das bei mir nicht funktioniert:
- Weiß jemand, ob es für 6.x eine brauchbare Lösung mit der genannten Funktionalität gibt?
- Würde mich jemand ggf. unterstützen, falls ich eine o.g. Lösung versuchen würde zu implementieren (meine DP-Fähigkeiten eigne ich mir gerade erst durch intensive Lektüre von DP-Seiten und Literatur an)
- Kann mir jemand mit deutlich mehr Erfahrung eine Perspektive zeichnen, wie wahrscheinlich und möglich die dauerhafte Etablierung einer solchen Erweiterung ist (kann ja sein, daß ein Hexentanz aufgeführt wird à la "Er hat URL-Sessionid gesagt, verbrennt ihn!", darauf hätte ich keinen Bock).
Wäre super, denn ich hab eigentlich keine Lust, daß die ganze Migration an diesem einen, essentiellen Punkt scheitert ;-)
Danke!
xhtmlperljavascriptcssdelphivbaphp - und nu auch noch das!
Klappt jetzt!
am 14.05.2009 - 19:55 Uhr
Selbst ist der Mann - ich habe nun die Drupalcenter-Version 6.11 frisch installiert und in Anlehnung an den beschriebenen Patch folgende Dinge geändert:
************************
1.) /sites/default/settings.php
alt:
ini_set('session.use_only_cookies', 1);ini_set('session.use_trans_sid', 0);
ini_set('url_rewriter.tags', '');
neu:
ini_set('session.use_only_cookies', 0);ini_set('session.use_trans_sid', 1);
ini_set( 'url_rewriter.tags' , 'a=href,area=href,frame=src,input=src,form=,fieldset=' );
2.) /includes/session.inc
2.1. in function sess_read
alt:
// Handle the case of first time visitors and clients that don't store cookies (eg. web crawlers).if (!isset($_COOKIE[session_name()])) {
$user = drupal_anonymous_user();
return '';
}
neu (Abschnitt auskommentiert):
/** Patch Session-ID-Handling // Handle the case of first time visitors and clients that don't store cookies (eg. web crawlers).if (!isset($_COOKIE[session_name()])) {
$user = drupal_anonymous_user();
return '';
}
*/
2.2. in function sess_write
alt:
// If saving of session data is disabled or if the client doesn't have a session,// and one isn't being created ($value), do nothing. This keeps crawlers out of
// the session table. This reduces memory and server load, and gives more useful
// statistics. We can't eliminate anonymous session table rows without breaking
// the throttle module and the "Who's Online" block.
if (!session_save_session() || ($user->uid == 0 && empty($_COOKIE[session_name()]) && empty($value))) {
return TRUE;
}
neu (wiederum auskommentiert):
/** patch SessionID // If saving of session data is disabled or if the client doesn't have a session,// and one isn't being created ($value), do nothing. This keeps crawlers out of
// the session table. This reduces memory and server load, and gives more useful
// statistics. We can't eliminate anonymous session table rows without breaking
// the throttle module and the "Who's Online" block.
if (!session_save_session() || ($user->uid == 0 && empty($_COOKIE[session_name()]) && empty($value))) {
return TRUE;
}
*/
2.3. in function sess_regenerate
alt:
if (isset($_COOKIE[session_name()])) {setcookie(session_name(), '', time() - 42000, '/');
}
neu (und abermals auskommentiert):
/** patch Sessionid if (isset($_COOKIE[session_name()])) {setcookie(session_name(), '', time() - 42000, '/');
}
*/
3. /includes/common.inc
3.1. in function drupal_goto
alt:
else if (isset($_REQUEST['edit']['destination'])) {
extract(parse_url(urldecode($_REQUEST['edit']['destination'])));
}
$url = url($path, array('query' => $query, 'fragment' => $fragment, 'absolute' => TRUE));
neu:
else if (isset($_REQUEST['edit']['destination'])) {
extract(parse_url(urldecode($_REQUEST['edit']['destination'])));
}
// Patch SessionID Start:
if (ini_get('session.use_trans_sid') && session_id() && !strstr($query, session_id())) {
$sid = session_name() . '=' . session_id();
if (!empty($query) && !strstr($query, $sid)) {
$query = $query .'&'. $sid;
}
else {
$query = $sid;
}
}
// Patch SessionID Ende
$url = url($path, array('query' => $query, 'fragment' => $fragment, 'absolute' => TRUE));
************************
Funktionalität nach diesen Änderungen:
User, die Cookies akzeptieren, werden wie gehabt behandelt. Wer ohne Cookies kommt, erhält im gewohnten PHP-Stil eine Sessionid, die in allen URLs, Formularen etc. weitergereicht wird.
Zu beachten/noch zu machen:
* Links auf externe Inhalte werden zwar nicht mehr mit der SID behängt, im HTTP-Referer wird diese aber natürlich mitgeliefert. Eine entsprechende Gatewayseite sollte hier also bereits gesäubert arbeiten (z.B. mittels Location-Refresh).
* Natürlich erhält nun jeder Crawler etc. ebenfalls eine SID. Das könnte man möglicherweise im nächsten Schritt so verfeinern, daß eben nur bei authentifizierten Usern das URL-Modell zum Zuge kommt. So macht es mein altes System noch, ich werde versuchen, das in DP auch noch einzubauen.
* Das ganze ordentlich administrierbar machen, sodaß es via systemweit hinterlegter Einstellung einfach im Admin-Bereich nach Belieben hin- und hergeschaltet werden kann.
* Infolgedessen bzw. als Voraussetzung dafür das ganze in ein ordentliches Modul/Patchpaket stopfen. Keine Ahnung bisher, wie/was/wo.
Fragen von mir:
* Wer kann mir verklickern/helfen die letzten beiden Punkte umzusetzen/zu verstehen?
* Von mir nicht bedachte Lücken der Sache?
Hoffe, das hilft nicht nur mir. Gruß
xhtmlperljavascriptcssdelphivbaphp - und nu auch noch das!
Was bedeutet es schon das Du
am 14.05.2009 - 19:52 Uhr
Was bedeutet es schon das Du die 6.11 installiert hast? Nix.
Aktuell ist 6.12. :-)
------------------------
Quiptime Group
Da geht noch was.
Eine ganze Menge...
am 14.05.2009 - 19:57 Uhr
...denn für mich bedeutet es, daß mein Hauptblocker weg ist. Das ist mir wichtiger, als Versionswettläufe.
Aber: Danke für den konstruktiven Input!
xhtmlperljavascriptcssdelphivbaphp - und nu auch noch das!
Das hat nichts mit einem Wettlauf zu tun.
am 14.05.2009 - 20:22 Uhr
Es muss ja nicht immer zwingend konstruktiv sein wenn man etwas postet. Auf jeden Fall ist 6.12 wie auch 6.11 ein Sicherheitsupdate. Deswegen kann man in meinem Post (ist quasi ein Hinweis), wenn an moechte, Konstruktivitaet sehen.
Das hat nichts mit einem Wettlauf zu tun.
------------------------
Quiptime Group
Da geht noch was.
Finde ich prima
am 15.05.2009 - 12:42 Uhr
prima, denke mal dass es einige gibt, denen das weiterhilft. Und an die aktuelle Version ist es dann ja sicherlich schnell angepasst.
nur so zumindstens die
am 21.05.2009 - 15:29 Uhr
nur so
zumindstens die session.inc kannste ohne Hacken ändern
per variable_set('session_inc', 'datepfadneuesessioninc');
--------------
Blog www.freeblogger.org: Deutscher IRC-Channel: irc.freenode.net #drupal.de ... Jabber-me: dwehner@im.calug.de
SirFiChi ist auch dein Halbgott.
Variablen zur Laufzeit, wo?
am 21.05.2009 - 15:40 Uhr
Danke für den Hinweis! Kannst Du mir noch sagen, wo ich so eine Änderung am besten implementiere?
Lassen sich so auch "common"-Variablen ändern und womöglich gar Core-Funktionen "overriden"?
Das wäre dann ja schon ein erheblicher Ansatz, das ganze dauerhaft nutzbar zu machen.
:-)
xhtmlperljavascriptcssdelphivbaphp - und nu auch noch das!
nein für die comment.inc
am 21.05.2009 - 15:53 Uhr
nein für die comment.inc gibts sowas nicht :(
Ich glaube du solltest einfach auf den Drupal Way von Formularen usw. gehen, denn zumindestens fasst du hier sehr zentrale Teile an, was nicht unbedingt die Sicherheit verbessert ;)
Zudem wird dir niemand helfen können, falls du ein Problem hast && updates sind nerviger
--------------
Blog www.freeblogger.org: Deutscher IRC-Channel: irc.freenode.net #drupal.de ... Jabber-me: dwehner@im.calug.de
SirFiChi ist auch dein Halbgott.
"Richtig"
am 21.05.2009 - 16:18 Uhr
Ich glaube du solltest einfach auf den Drupal Way von Formularen usw. gehen
"Bahnhof?" was ist gemeint? Hinnehmen, daß es keine Sessionid im URL gibt? Dazu hatte ich doch aber schon eingangs was geschrieben :-(
Aber falls Du damit meinst "es sauber und updatebeständig in der allgemein etablierten Form machen", wäre ich, sehr dankbar für Hilfe. Zum Beispiel wie gesagt daß Du mir verrätst wie/wo man außerhalb des Kerns diese Variable "sauber" patcht und ggf. Funktionen erweitert/overridet.
Zumal Login ohne Cookies früher ja möglich _WAR_, bis es aus vermeintlich "nicht ausreichendem Interesse" nicht weiter verfolgt wurde! (Wie und durch wen wird sowas eigentlich gemessen? Ich kenne ja mindestens schon zwei, die eben doch interessiert sind. Und die sind doch hoffentlich nicht "egal", nur weil sie nicht die Masse sind? ;))
Die Entscheidung, ob die Option letztlich genutzt wird, darf man meiner Meinung nach doch getrost dem jeweiligen Seitenbetreiber überlassen, zum Beispiel, indem man die betreffende Option von Hause aus deaktiviert und bei Aktivierung eine entsprechende Warnung ausgibt. Das wäre ein sowohl sauberer, als auch im Sinne von freier SW "korrekterer" Weg, verglichen mit einer willkürlich vorweggenommen Entscheidung à la "das ist zwar möglich, aber nicht gut für dich, also darfst du es nicht".
Außerdem und das auch noch mal ausgeführt: Eine Gateway-Seite für externe Links, die einen Sessionid-losen Übergang sicherstellt, ist eine gute Lösung. Auch das könnte man in so ein Modul mit integrieren: Optional, wenn aktiviert, die gerenderte Seite unmittelbar vor der Auslieferung automatisch noch einmal links zu externen (bzw. solchen, die nicht explizit als intern definiert sind) Hosts zu überprüfen und diese auf eine solche Gatewayseite umzulenken.
Sorry, ich käue wieder. Aber da es mir wichtig ist und ich sowas in meinem Spaghettisystem funktionierend drinhabe, werde ich es, sobald ich das gut genug kann, gerne selbst DP-konform implementieren. Wer mir dabei vorher schon helfen will, ist mir weiterhin hochwillkommen. :-)
xhtmlperljavascriptcssdelphivbaphp - und nu auch noch das!