Session und Browser-Tabs

[dr.Colossos]

Hi,

ich ahbe eine Seite in der dynamisch iframes erzeugt werden.

Es soll auch moeglich sein, dass der User die Seite in mehreren Browserfenstern/-tabs oeffnet.

Ich gehe dabei wie folgt vor:

[index.php]
[...]
// User noch nicht eingelogged
if(!$_SESSION['logged_in'])
{
 // neuen Login erzeugen
 $login_window = new LoginWindow();
 $login_window->show();

// Login erfolgreich => Session erstellen, und login-Flag sezten
 if($login_window->success())
 {
  session_name('sess_name_'.uniqid());
  session_id(md5(uniqid()));
  session_start();
  $_SESSION['logged_in'] = TRUE;
 }
}
[...]

Die Session-ID sowie den Namen der Session gebe ich an jedes neue Fenster weiter, und fuehre ...

session_name(GET['session_name']);
session_id(GET['session_id']);
session_start();
[...]
... aus.

Soweit duerfte ja alles passen, oder?

Allerdings hat dieser Ansatz ein Problem.

Mit jedem Refresh (F5 o.ae.) wird nicht nur NICHT die aktuelle Session WEITERGEFUEHRT, es wird eine NEU Session ERSTELLT, und die VORHERIGE nicht GELOESCHT, da ich in diesem Fall ja nicht an den Namen oder die ID der aktuellen Session komme.

Daher meine Fragen:
Ist mein Ansatz okay?
Wie koennte man das besser loesen?
Kann bei Refreshs oder bei Wiedereingabe der URL trotzdem die aktuelle Session fortsetzen, und wenn ja, wie?

Danke fuer eure Hilfe.

[Sven Rautenberg]

Moin!

ich ahbe eine Seite in der dynamisch iframes erzeugt werden.

Das ist ja absolut undramatisch.

Es soll auch moeglich sein, dass der User die Seite in mehreren Browserfenstern/-tabs oeffnet.

Ebenso.

Ich gehe dabei wie folgt vor:

Du gehst falsch vor.

[index.php]
[...]
// User noch nicht eingelogged
if(!$_SESSION['logged_in'])

An dieser Stelle muß schon session_start() aufgerufen worden sein.

Deshalb kannst du später...

{
// neuen Login erzeugen
$login_window = new LoginWindow();
$login_window->show();

// Login erfolgreich => Session erstellen, und login-Flag sezten
if($login_window->success())
{

...hier den Session-Namen und die Session-ID nicht mehr setzen und die Session neu starten:

session_name('sess_name_'.uniqid());
  session_id(md5(uniqid()));
  session_start();

Außerdem besitzt PHP bereits einen sehr guten Algorithmus zur Erzeugung einer nicht ratbaren Session-ID, so dass dein Versuch, ihn nachzubilden, keinerlei Vorteil bringt. Ebenso scheitert der Versuch, den Session-Namen mit der uniqid() anzureichern, denn damit erzeugst du nicht vorhersagbare Session-Namen, d.h. PHP kann die Session-ID nicht mehr aus dem (konstanten) Session-Name-Parameter (in URL oder Cookie) herausfiltern, weil sich dieser Parameter ja auch ständig ändert. Im Endeffekt müßtest du nahezu sämtliche Arbeiten, die PHP allein perfekt erledigt, mit eigenem PHP-Code nachbilden, ohne auch nur den geringsten Sicherheitsgewinn (ich vermute das mal als Motivation dahinter) zu erreichen.

$_SESSION['logged_in'] = TRUE;
}
}

Die Session-ID sowie den Namen der Session gebe ich an jedes neue Fenster weiter, und fuehre ...

Wie?

session_name(GET['session_name']);
session_id(GET['session_id']);
session_start();

Meinst du nicht auch, dass es reichlich überkandidelt ist, den dynamischen Session-Namen an einen statischen Session-Namen-Parameter zu binden, und die dynamische Session-ID an einen statischen Session-ID-Parameter, nur um dann intern den dynamischen Session-Namen mehr oder weniger nutzlos wegzuwerfen, und nur die Session-ID vom statischen Session-ID-Parameter zu nutzen - ganz genau so, wie PHP es auch selbst tut?

Soweit duerfte ja alles passen, oder?

Du hast dir soviele Fehlerquellen eingebaut, dass ich ohne Bedenken "Nein!" antworten kann. Denn andernfalls hättest du ja keine Probleme, oder? :)

Allerdings hat dieser Ansatz ein Problem.

Mit jedem Refresh (F5 o.ae.) wird nicht nur NICHT die aktuelle Session WEITERGEFUEHRT, es wird eine NEU Session ERSTELLT, und die VORHERIGE nicht GELOESCHT, da ich in diesem Fall ja nicht an den Namen oder die ID der aktuellen Session komme.

Das ist eben dein Problem, dass du dir durch den dynamischen Session-Namen einhandelst.

Daher meine Fragen:
Ist mein Ansatz okay?

Absolut nicht.

Wie koennte man das besser loesen?

Nutzen den Session-Mechanismus von PHP "nackt", ohne eigene Nachbesserungen. Der funktioniert sehr sehr gut.

Kann bei Refreshs oder bei Wiedereingabe der URL trotzdem die aktuelle Session fortsetzen, und wenn ja, wie?

Wenn man PHPs Session-Mechanismus normal nutzt, klappt in der Regel alles.

- Sven Rautenberg

[dr.Colossos]

Servus,

nun ja, ich habe sehr viel mi PHP gemacht, aber wenig mit Sessions.

Teile des Codes (u.a. das uniqid()) habe ich online Beispielen nach empfunden, die auch pro Tab eine Session wollten - irgendwo muss man ja anfangen.

Nun gut, ich werds umbauen.

Aber ich brauche ja verschiedene Session-Namen, daher hab ich das mit uniqid() uebernommen. Soll ich da lieber einen Pool von Session-Namen erstellen, wie PHPSESS_0, PHPSESS_1, ... PHPSESS_N?

Die Session-ID sowie den Namen der Session gebe ich an jedes neue Fenster weiter, und fuehre ...

Wie?

session_name(GET['session_name']);
session_id(GET['session_id']);
session_start();

Ehhm, naja, per URL, ich haeng die ID und den Namen hinten an.

Meinst du nicht auch, dass es reichlich überkandidelt ist, den dynamischen Session-Namen an einen statischen Session-Namen-Parameter zu binden, und die dynamische Session-ID an einen statischen Session-ID-Parameter, nur um dann intern den dynamischen Session-Namen mehr oder weniger nutzlos wegzuwerfen, und nur die Session-ID vom statischen Session-ID-Parameter zu nutzen - ganz genau so, wie PHP es auch selbst tut?

Naja, aber ich muss den Namen und die ID ja ermitteln und weiterreichen koennen, sonst startet in jedem iframe eine neue Session weil die ID nicht uebereinstimmt, den Namen brauche ich, dass die richtige weitergefuehrt wird.

Tut mir leid, versteh dich hier nicht so recht ... Bespiel?

Danke sehr!

[Sven Rautenberg]

Moin!

Teile des Codes (u.a. das uniqid()) habe ich online Beispielen nach empfunden, die auch pro Tab eine Session wollten - irgendwo muss man ja anfangen.

Ich dachte, du willst, dass man mehrere Tabs parallel benutzen kann. Das impliziert für mich "eine Session für alle Tabs".

- Sven Rautenberg

[dr.Colossos]

Hehe,

nein, eben genau nicht - sorry wenn das von mir nicht ausreichend dargelegt wurde.

Es ist eine Applikation, und ich bin gerade beim Neuaufbau des Kerns.

Es wurde oefter verlangt, dass man sich an einem Rechner mehrmals anmelden kann.

Ohne mehrfache Sessions ueberschreibt bei jedem Reload/Klick das eine Fenster/Tab die Session der anderen.

Stell dir z.B. ein Menue vor, deren offenen Menueeintraege per Session gehandelt werden.

• In Tab 1 ist A, B offen
• neuer Tab 2 -> A, B werden sofort geoeffnet
• oeffnen von Eintrag C in Tab 2
• Reload Tab 1, C offen

Beim Menue waere mir das reichlich egal, aber man kann sich schon vorstellen, dass das haessliche Folgen haben kann.

Daher soll jeder Tab/jedes Fenster eine EIGENE Session haben.

Das heisst, mein uebergeben der Session-ID und des Session-Namens war nicht falsch, oder?

Danke nochmals

[Tom]

Hello,

Daher soll jeder Tab/jedes Fenster eine EIGENE Session haben.

Lass uns mal überlegen, was denn ein Standardbrowser dazu sagt.
Angenommen, man hat in einem Tabulator-Fenster das SelfForum mit der benutzerdefinierten Darstellung in Benutzung. Nun öffnet man ein neues Tabulator-Fenster und ruft darin das Forum nochmal auf. Was wird wohl beim request passieren?

Genau!

Der brave Browswer schaut bei seinen Cookie-Pfade nach, ob sich nicht was passendes findet und sendet den Cookie für Selfhtml mit, denn innerhalb eines Browsers ist das für ihn derseslbe Benutzer der davor sitzt. Der weiß ja nicht, dass aus Paul inzwichen Paulinchen geworden ist...

Zwei Sessions parallel auf denselben Ressourcenpool aus demselben Browser heraus halte ich für nicht möglich.

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom

[Der Martin]

Hallo Tom,

Zwei Sessions parallel auf denselben Ressourcenpool aus demselben Browser heraus halte ich für nicht möglich.

um deine Beschreibung zu ergänzen: Nicht möglich, wenn die Session ID per Cookie transportiert wird. Wird die Session ID dagegen als URL-Parameter mitgeschleppt, ist das durchaus möglich[*].

So long,
 Martin

[*] Ein Leben ohne Möpse ist möglich, aber sinnlos.   [Loriot]

[Tom]

Hello,

Zwei Sessions parallel auf denselben Ressourcenpool aus demselben Browser heraus halte ich für nicht möglich.

um deine Beschreibung zu ergänzen: Nicht möglich, wenn die Session ID per Cookie transportiert wird. Wird die Session ID dagegen als URL-Parameter mitgeschleppt, ist das durchaus möglich[*].

Wenn Du das ssooo sagst :-)

Muss ich ja zugeben, ich habe nur die beiden automatisch vom Browser unterstützten verdeckten Methoden
a) Cookie
b) (Basic|Digest) Authentification

bedacht, nicht das transparente Sessionhandling.

[*] Ein Leben ohne Möpse ist möglich, aber sinnlos.   [Loriot]

*grins*

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom

[Dennis]

Hi Tom,

[*] Ein Leben ohne Möpse ist möglich, aber sinnlos.   [Loriot]

*grins*

Laut Wikipedia heißt das Zitat aber etwas anders:

„Ein Leben ohne Mops ist möglich – aber sinnlos!”   [Loriot]

;-)

Viele Grüße,
  ~ Dennis.

[dr.Colossos]

Hi,

hier mein neuer Code, offen zur Diskussion.

// session stoppen wenn entsprechendes Signal kommt
if(array_key_exists('logout', $_POST))
{
 // vor destroy() muss Session nochmals gestartet werden, sonst PHP-Warning bei destroy()
 session_id($_POST['logout']);
 session_start();
 session_destroy();
 unset($_SESSION);
}

// SESSION-ID nicht uebergeben => neuer Aufruf der Seite
if(!array_key_exists('SESSION_ID', $_POST))
{
 $_SESSION['logged_in'] = FALSE; // to avoid undefinded index notices
 $_POST['SESSION_ID'] = md5(uniqid('')); // irgendwas eindeutiges ... session_id() oder session_id_regenerate() lieferten hier immer ''/FALSE
 $_POST['SESSION_NAME'] = 'pro_ject_'.uniqid(''); // nochmal irgendwas eindeutiges

// ID und Name automatisch ueberall an URL anhaengen ... bequem, aber haesslich
 output_add_rewrite_var('SESSION_ID', $_POST['SESSION_ID']);
 output_add_rewrite_var('SESSION_NAME', $_POST['SESSION_NAME']);
}
// SESSION-ID uebergeben => entsprechende Session wieder starten
else
{
 session_id($_POST['SESSION_ID']);
 session_name($_POST['SESSION_NAME']);
 session_start();
}

// Login-Fenster anzeigen, liefert nur Code wenn Login noetig
$login_window = new LoginWindow(array());
if(strlen($output = $login_window->get_html_code()) > 0)
 show($output);
// ... ansonsten wurde der User erfolgreich eingelogged
else
 $_SESSION['logged_in'] = TRUE;

[Sven Rautenberg]

Moin!

hier mein neuer Code, offen zur Diskussion.

Nachdem ich nochmal eine Weile drüber nachgedacht habe, und auch mit Toms Einwurf, komme ich zu der Überzeugung, dass der Aufwand nicht so riesig sein muß.

Es sollte vollkommen ausreichen, wenn du bei PHP einfach die Nutzung von Cookies für die Sessions deaktivierst. Auf diese Weise gelangt die Session-ID eines Requests nur noch per URL oder POST-Daten zum Server.

Das wiederum bedeutet aber, dass jeder Request eine individuelle Session-ID haben kann, auch wenn im gleichen Browser andere Fenster parallel existieren. Denn eine für den gesamten Browser geltende Session kommt ja erst deshalb zustande, weil Cookies pro Domain gelten und von allen Requests dorthin genutzt werden.

- Sven Rautenberg

[dr.Colossos]

Hi,

Es sollte vollkommen ausreichen, wenn du bei PHP einfach die Nutzung von Cookies für die Sessions deaktivierst.

Du meinst in der php.ini ...

session.use_cookies = "0"

... setzen reicht?

Ich muss ja trotzdem Session-ID/Name uebergeben, oder?

Und dass ist genau was mein Code macht, nur halt mit dem etwas (meines Erachtens haesslichem) output_add_rewrite_var(VAR_NAME, VAR_VALUE); jeweils einmal fuer Session-ID und Session-Name.

[Tom]

Hello,

Es sollte vollkommen ausreichen, wenn du bei PHP einfach die Nutzung von Cookies für die Sessions deaktivierst.

Du meinst in der php.ini ...

session.use_cookies = "0"

... setzen reicht?

session.use_trans_sid = 1  muss auch noch gesetzt werden.

Beliebte Standardeinstellungen sind:

session.use_cookies         On On
session.use_only_cookies Off Off
session.use_trans_sid         0 0

Ich muss ja trotzdem Session-ID/Name uebergeben, oder?

Das wiederum macht PHP alleine.

session.name                PHPSESSID PHPSESSID

wäre da die Voreinstellung. Wenn Du einen anderen willst, was bei Dir ja der Fall sein muss, musst Du den VOR dem session_start() mit session_name('NEUER_NAME') setzen.

Und dass ist genau was mein Code macht, nur halt mit dem etwas (meines Erachtens haesslichem) output_add_rewrite_var(VAR_NAME, VAR_VALUE); jeweils einmal fuer Session-ID und Session-Name.

Das macht dann der Webserver.

Und den Code hätte ich gerne, den kann ich dann noch weiterverwenden :-)

Ich wollte es Dir nach Martins Einwurf auf mein "mit verdeckten Methoden geht es nicht" erst posten, aber dann dachte ich darüber nach, dass ich vorher lieber noch die Sicherheitslücke, die ich darin ahne, überprüfen wollte. Ich bin mir nämlich nicht sicher, ob ausschließlich die Links und Action-Attribute für die eigene Domain von PHP umgeschrieben werden, oder auch solche, die auf Fremdseiten verweisen.

Das wäre nämlich gar nicht schön, weil Deine Nutzer dann Deine Session-IDs auch noch unter Beigabe des  Referers breit in der Gegend verstreuen würden.

Wie gesagt, ich habe es noch nicht ausprobiert. Das solltest Du dann mal machen. Wie Du es überprüfen kannst, weiß ich noch nicht. Vielleicht mit ob_start()? Ich weiß aber nicht, wann PHP die Ersetzungen durchführt, vor oder nach dem ob_end_*()

Da hilft dann vielleicht eine zweite Domain, auf die Du Zugriff hast.

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom

[dr.Colossos]

Hi,

Beliebte Standardeinstellungen sind:

session.use_cookies         On On
session.use_only_cookies Off Off
session.use_trans_sid         0 0

Mmmh, session.use_trans_sid = 0 ... schon mal gehoert ...

PHP.net meint dazu:
Hinweis: In PHP 4.1.2 oder darunter wird sie durch compilieren mit --enable-trans-sid aktiviert. Ab PHP 4.2.0 ist das Feature trans-sid immer eincompiliert. URL-basiertes Session-Management hat im Vergleich zu Cookie-basiertem Session-Management zusätzliche Sicherheitsrisiken. Benutzer können zum Beispiel eine URL, die eine aktive Session-ID enthält, per Email an Freunde schicken oder in ihren Bookmarks speichern und immer mit der selben Session-ID auf Ihre Seite zugreifen.

Mir is klar, dass wenn ich mit output_add_rewrite_var das ganze mache, letzendlich das selbe mache, aber zumindest is die Session-ID nicht in der URL sichtbar.
Mag sein, dass das so auch nicht sichtbar ist, kann das im Moment nicht testen ...

Ich wollte es Dir nach Martins Einwurf auf mein "mit verdeckten Methoden geht es nicht" erst posten, aber dann dachte ich darüber nach, dass ich vorher lieber noch die Sicherheitslücke, die ich darin ahne, überprüfen wollte. Ich bin mir nämlich nicht sicher, ob ausschließlich die Links und Action-Attribute für die eigene Domain von PHP umgeschrieben werden, oder auch solche, die auf Fremdseiten verweisen.

Naja, vom Prinzip duerfte es ja aehnlich laufen wie bei dem von mir benutzten output_add_rewrite_var().

PHP.net sagt da:
Bitte beachten Sie das nur relative URLs, nicht aber absolute wie bei  http://example.com/... automatisch erweitert werden.

Sollte also passen, oder?

Werd mir das spaeter ansehen ...

Danke, auch fuer weitere Ideen/Meinungen

[Tom]

Hello,

Mir is klar, dass wenn ich mit output_add_rewrite_var das ganze mache, letzendlich das selbe mache, aber zumindest is die Session-ID nicht in der URL sichtbar.
Mag sein, dass das so auch nicht sichtbar ist, kann das im Moment nicht testen ...

Das sollte man eigentlich steuern können über die Einstellung url_rewriter.tags

[http://de2.php.net/manual/en/ref.session.php]

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom

[dr.colossos]

Hi,

mit den "beliebten Standardeinstellungen" ...

session.use_cookies  1
session.use_only_cookies 0
session.use_trans_sid  1

... hab ich nun folgenden (sehr maessig getesteten!) Code. Aber ich poste ihn gleichmal, bevor ich's vergesse ...

[...]
$session_name = null;
// erschoepfende Suche nach dem session-namen, der mit "some-fancy-prefix-" beginnt, gefolgt von einer uniqid()
if(is_array($_POST))
{
 foreach($_POST as $key => $value)
 {
  // Suche erfolgreich => Session-Namen uebernehmen
  if(strpos($key, 'some-fancy-prefix-') > 0)
   $session_name = $key;
 }
}
// Suche nicht erfolgreich => neuen Sessionnamen uebernehmen
if($session_name == null)
 $session_name = 'some-fancy-prefix-'.uniqid('');

// Session starten
session_name($session_name);
session_start();

// Session stoppen wenn entsprechendes Signal kommt
if(array_key_exists('logout', $_POST))
{
 session_destroy();
 unset($_SESSION);
}
[...]

Ist das was du/ihr in etwa erwartet hast/habt?

Meinungen? Lobpreisungen? Blanko-Checks?

Danke & Servus

[dr.colossos]

Hey,

[...]
// Suche erfolgreich => Session-Namen uebernehmen
if(strpos($key, 'some-fancy-prefix-') > 0)
[...]

... sollte heissen ...

[...]
// Suche erfolgreich => Session-Namen uebernehmen
if(strpos($key, 'some-fancy-prefix-') !== FALSE)
[...]

Ausserdem:
Bei Login wird die Session-ID als hidden field in den Quelltext geschrieben, komischerweise aber beim Logout nicht. Kann sich jemand denken an was das liegt?

Wird beides ueber die index.php gemacht. Der login sendet die Daten ebenfalls wieder an die index.php, wo auch ein Button fuer den Logout generiert wird ... hmmm ... no idea ..?

Gute Nacht

[Tom]

Hello,

session.use_cookies  1
session.use_only_cookies 0
session.use_trans_sid  1

Für Deinen Fall solltest Du benutzen

session.use_cookies      0
  session.use_only_cookies 0
  session.use_trans_sid    1

... hab ich nun folgenden (sehr maessig getesteten!) Code. Aber ich poste ihn gleichmal, bevor ich's vergesse ...

[...]
$session_name = null;
// erschoepfende Suche nach dem session-namen, der mit "some-fancy-prefix-" beginnt, gefolgt von

einer uniqid()

Verstehe nicht, was und wofür Du das hier machst.

if(is_array($_POST))

$_POST, $_GET und $_SERVER sind immer Arrays und auch immer vorhanden, wenn man nicht selber daran manipuliert hat oder der Parser beschädigt ist.

{
foreach($_POST as $key => $value)
{
  // Suche erfolgreich => Session-Namen uebernehmen
  if(strpos($key, 'some-fancy-prefix-') > 0)

if(strpos($key, 'some-fancy-prefix-') !== false)  ## !false! steht für "nicht gefunden"

$session_name = $key;
}
}
// Suche nicht erfolgreich => neuen Sessionnamen uebernehmen
if($session_name == null)
$session_name = 'some-fancy-prefix-'.uniqid('');

// Session starten
session_name($session_name);
session_start();

// Session stoppen wenn entsprechendes Signal kommt
if(array_key_exists('logout', $_POST))
{
session_destroy();
unset($_SESSION);
}

PHP bezeichnet seine Sessions i.d.R. mit 'PHPSESSID',
das kann man mit session_name() abfragen und _verändern_.
Dieser Name wird dann auch z.B. für den Cookie, für die Variable in $_POST (im Formular also für die Hidden-Var), für den Parameter in der URi (in allen[?] Links also) benutzt.

Die Datei, die dann angelegt, gesucht, bearbeitet wird, wird i.d.R. mit SESS_<nummer> gekennzeichnet.

Die Nummer ist die hexadezimale Darstellung der Session-ID.
Die Nummer wird von PHP nach einem bestimmten (Zufalls-)Algorithmus ausgewürfelt, und soll angeblich "nicht erratbar" sein. man kann sie mit session_id() abfragen und auch _setzen_

Wenn Du nun die Werte für Sessionname und Session-ID nach Deinem Gutdünken festlegst, _bevor_ Du
session_start() aufrufst, macht PHP alles für Dich.

Es benutzt den festgelegten Sessionnamen und die festgelegte ID, um nach der vermeintlich vorhandenen Sessiondatei zu schauen in session.save_path und wenn die dort nicht vorhanden ist, eine neue unter der Nummer mit der Bezeichnung SESS_<nummer> anzulegen. Der Name spielt hier keine Rolle mehr. Der war nur gut für die Übermittlung der Session-Nummer zwischen Client und Server.

Wenn PHP (gemeint ist immer der Prozess) uf Betriebssystem-Ebene keine Schreib- oder Leserechte für das Verzeichnis, das in session.save_path angeben wurde, hat, dann kracht es. Es gibt dann eine Warning. Wenn PHP keine Berechtigung hat, weil der angegebene Pfad nicht in open_basedir aufgeführt ist (nicht dazu passt), dann kracht es ebenfalls.

Kleiner Ausflug nebenbei:
Wenn man in seiner shared-Hosting-Umgebung seine Session-Dateien im allgemeinen /tmp/-Verzeichnis ablegen lässt, ist man dämlich, da dies meistens scanbar ist (wegen des Garbage Collectors) und die Sessions dann entführbar sind. Wenn wenigstens das R-Recht fürs Verzeichnis entzogen wurde, müsste man sie erraten, um darauf zuzugreifen; das würde wenigstens relative Sicherheit geben.

Wenn Du also in $_POST nachschauen willst, ob eine Session-Kennung von/für PHP angekommen ist, dann
kannst du das mit

if (isset($_POST[$session_name()]))

und kannst dann die Kennung aus dem Arrayelement herauslesen. Das musst Du aber gar nicht, weil PHP das ja selber tut, und diese verwendet, wenn Du nicht mit session_id() selber eine eigene festgelegt hast.

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom

[dr.colossos]

Hi,

Für Deinen Fall solltest Du benutzen

session.use_cookies      0
  session.use_only_cookies 0
  session.use_trans_sid    1

Okay, danke!

// erschoepfende Suche nach dem session-namen, der mit "some-fancy-prefix-" beginnt, gefolgt von
einer uniqid()

Verstehe nicht, was und wofür Du das hier machst.

Naja, ich muss ja den Sessionnamen ermitteln, um die entsprechende Session wieder aufnehmen zu koennen.

Wenn ich nur session_name() aufrufe, bekomm ich immer "PHPSESSID" zurueck, egal ob beim 1. Aufruf, oder nach dem Login.

Daher durchforste ich das POST-Array, da steht ein Eintrag der Form

$_POST[some-fancy-prefix474edae46330d] = 'db77e543a96ec5aa7b7f32ae2caaeb1a';

Ich suche daher nach was das mit 'some-fancy-prefix' beginnt, und weiss dann den vollstaendigen Namen der Session.
Wurde keiner im POST-Array gefunden (1. Aufruf), dann wird $session_name initialisert mit 'some-fancy-prefix'.uniqid()

session_name($session_name);   // $session_name ist hier z.B. "some-fancy-prefix474edae46330d"
session_start();    // Session starten

Auch mit deiner Erklaerung (danke dafuer!) weiter unten weiss ich nicht, wie ich es kuerzer machen koennte.

Klar, wenn ich irgendwie (direkt) an den Session-Namen kommen wuerde, muesste ich nicht danach suchen, aber wie oben erwaehnt, session_name() liefert immer PHPSESSID, bis zu dem Punkt wo ich ihn auf was anderes setze.
Nach einem POST ist der Name aber wieder PHPSESSID.

Was versteh ich falsch?

[Tom]

Hello,

Verstehe nicht, was und wofür Du das hier machst.

Naja, ich muss ja den Sessionnamen ermitteln, um die entsprechende Session wieder aufnehmen zu koennen.

Wenn ich nur session_name() aufrufe, bekomm ich immer "PHPSESSID" zurueck, egal ob beim 1. Aufruf, oder nach dem Login.

Daher durchforste ich das POST-Array, da steht ein Eintrag der Form

$_POST[some-fancy-prefix474edae46330d] = 'db77e543a96ec5aa7b7f32ae2caaeb1a';

Ich suche daher nach was das mit 'some-fancy-prefix' beginnt, und weiss dann den vollstaendigen Namen der Session.
Was versteh ich falsch?

Ich denke, schon.

Wenn alle Sessions auf Deinem Host über eine Basis abgewickelt werden, dann macht bei dem von Dir gewählten Verfahren keinen Unterschied, ob 10 Session-Requests von fünf verschiedenen Clients kommen, 10 Session-Requests von 20 Clients [1], oder jeweils 5 unterschiedliche Session-Requests von zwei Clients. Es werden immer 10 aktive Sessions betroffen sin davon

[1] Es dürfen natürlich auch Clients zugreifen, denen bisher gar keine Session zugeteilt wurde.

Der Name der Session-ID kann dann immer dersselbe sein. Die Sessions unterscheiden sich alleine durch den Wert der Session-ID. Du musst also gar kein "fancy-dings-bums" bauen. PHP sortiert Dir die Zugriffe schon automatisch über den Wert der Session-ID. Wenn eine passt, wird damit "reconnected", wenn keine passt, wird eben eine neue zugeteilt.

Nimm den Fancy-Krams einfach mal raus und Du wirst sehen, es funktioniert doch - oder gerade *g*

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom

[dr.colossos]

Hi,

Der Name der Session-ID kann dann immer dersselbe sein. Die Sessions unterscheiden sich alleine durch den Wert der Session-ID. Du musst also gar kein "fancy-dings-bums" bauen. PHP sortiert Dir die Zugriffe schon automatisch über den Wert der Session-ID. Wenn eine passt, wird damit "reconnected", wenn keine passt, wird eben eine neue zugeteilt.

Verschiedene Namen brauch ich aber wegen verschiedenen Tabs, den ein Tab darf sich NICHT die Session mit einem anderen Tab teilen.

Nimm den Fancy-Krams einfach mal raus und Du wirst sehen, es funktioniert doch - oder gerade *g*

Nope, eben nicht mehr, da dann Session A von Tab T1 und T2 genutzt wird, was aber nicht sein darf. Daher muss ich jeder Session (neben der automatisch vegebenen eindeutigen ID) auch einen eindeutigen Namen verpassen.

Da ich den aber nicht abspeichern kann, muss ich nach dem Namensmuster suchen ... okay, speichern koennte ich ihn schon, aber um ihn danach auslesen zu koennen muesste ich den Namen der Session wissen um den Namen aus der Session auslesen zu koennen ... das eher schlecht ...

[dr.colossos]

Hi,

okay, okay, hab's nochmal probiert, und du hast recht, es funktioniert.

Weiss nicht wieso, aber davor hat das nicht funktioniert, die Tabs haben sich immer die Session geteilt, wenn der Name der gleiche war.

Bin mir aber garnicht sicher ob ich das so lasse. Da ich php.ini-Einstellungen aendern musste, gefaellt mir das garnicht so.

Ich hab das mal alles in Klassen gekapselt, damit kann ich zwischen diesem, dem Output_Add_Rewrite-Verfahren und dem Standardverfahren (keine mehrfachen Sessions pro Tabs) wechseln.

Danke jedenfalls fuer die ausfuehrliche Hilfe!

[Tom]

Hello,

okay, okay, hab's nochmal probiert, und du hast recht, es funktioniert.

Weiss nicht wieso, aber davor hat das nicht funktioniert, die Tabs haben sich immer die Session geteilt, wenn der Name der gleiche war.

Das funktioniert nicht einfach so, sondern weil hier ein paar Leute darüber nachgedacht haben, was Andere (die PHP-Entwickler) schon vorgedacht hatten. Das ist leider nicht immer leicht und die Doku genau an diesen Stellen mMn nach zu dünn.

Es hat vorher nicht funktioniert, weil Deine Browser das Spiel nicht mitgespielt haben. Wenn die Sessions nämlich per Cookie oder per Auth Basic oder Digest geführt werden, dann sendet der Browser immer denselben Cookie bzw. dasselbe Pärchen Username:Passwort mit an die Domain, egal wieviele Fenster Du geöffnet hast.

Wenn Du aber keine Cookies und keine Credential für Auth mehr zur Verfügung stellst, kann der Browser nur die normalen Formulardaten oder die URL mitsenden. Die sieht er nicht als Session-relevant an und merkt sie sich daher auch nicht.

Lieder sendet er sie daher auch an externe Domains mit, wenn PHP JEDEN Link und jedes Action-Attribut manipuliert hat (vollqualifizierte Links auch...) oder das Verfahren wird unsicher, wenn nur relative Links manipuliert wurden. Das war genau das Thema, was ich noch als überprüfungswürdig eingestuft hatte.

Richtig wäre, wenn nur die Links und Actionattribute, die zur eigenen Domain gehören, manipuliert werden. Das ist aber bei JavaScript-Links wieder kritisch. Mit dem Cookie- oder Auth-Verfahren funktionieren die auch einwandfrei, mit transparenter Session-ID leider nicht.

Bin mir aber garnicht sicher ob ich das so lasse. Da ich php.ini-Einstellungen aendern musste, gefaellt mir das garnicht so.

Eine andere Möglichkeit sehe ich nicht, um parallele Sessions mit derselben Domain aus ein und demselben Browser führten zu können.

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom

[dr.colossos]

Hi,

Bin mir aber garnicht sicher ob ich das so lasse. Da ich php.ini-Einstellungen aendern musste, gefaellt mir das garnicht so.

Eine andere Möglichkeit sehe ich nicht, um parallele Sessions mit derselben Domain aus ein und demselben Browser führten zu können.

Naja, das Output_Add_Rewrite-Verfahren funktioniert ohne Aenderungen an der php.ini.

Klar, beide Verfahren erhoehen das Risiko, aber wer's benutzen will, der muss sich dessen auch bewusst sein.

Eine Session pro "Rechner" ist sicher am sicheresten.

Danke fuer deine Hilfe, bin mit dem Ergebnis sehr zufrieden!

[Auge]

Hallo

Richtig wäre, wenn nur die Links und Actionattribute, die zur eigenen Domain gehören, manipuliert werden. Das ist aber bei JavaScript-Links wieder kritisch. Mit dem Cookie- oder Auth-Verfahren funktionieren die auch einwandfrei, mit transparenter Session-ID leider nicht.

Ähm, wie sieht bei dir ein externer bzw. interner Link aus? Links zu externen Seiten können nur absolut sein, womit die SESSION-ID dort nicht angehängt wird. Interne Links können relativ angegeben werden, um das PHP-seitige anhängen der SESSION-ID zu erzwingen. Das Zitat zur Sache hat dr.colossus ja schon gebracht (ziemlich am Ende des verlinkten Postings). Wo siehst du da das Problem?

Bin mir aber garnicht sicher ob ich das so lasse. Da ich php.ini-Einstellungen aendern musste, gefaellt mir das garnicht so.

Die notwendigen Ein- bzw. Verstellungen zu session.use_cookies, session.use_only_cookies und session.use_trans_sid können auch per ini_set vorgenommen werden. Man muss also nicht auf die -eventuell unerreichbare- php.ini zurückgreifen.

Tschö, Auge

[Tom]

Hello,

Ähm, wie sieht bei dir ein externer bzw. interner Link aus?

Der interne verweist auf die eigene Domain, der externe auf eine Fremde.
PHÜ unterscheidet aber hier nicht nach Domain, sondern leider nach Scheme.

Dass extrerne Seiten nur mit Scheme angegeben werden können, ist ok, aber interne dürfen dies auch und dann hängt PHP da auch keine SID an, soweit ich das jetzt überschauen kann.

Die notwendigen Ein- bzw. Verstellungen zu session.use_cookies, session.use_only_cookies und session.use_trans_sid können auch per ini_set vorgenommen werden. Man muss also nicht auf die -eventuell unerreichbare- php.ini zurückgreifen.

Das ist wahr. Natürlich _bevor_ man die Session startet.

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom

[dr.colossos]

Hi,

Die notwendigen Ein- bzw. Verstellungen zu session.use_cookies, session.use_only_cookies und session.use_trans_sid können auch per ini_set vorgenommen werden. Man muss also nicht auf die -eventuell unerreichbare- php.ini zurückgreifen.

Das ist wahr. Natürlich _bevor_ man die Session startet.

Ja, dachte ich mir auch schon, habs aber nicht getestet.

Danke fuer die Info, das macht den session.use_trans_sid wieder realistischer.

Es is ja so, dass wenn auf einem Server PHP einmal installiert ist, die php.ini Einstellungen fuer alle PHP-Prozesse gelten, solange man nicht was an der Konfiguration aendert [keine Ahnung ob es geht das Applikation A mit einer php.ini arbeitet, Applikation B mit einer anderen, denke mal schon dass das irgendwie machbar waere ... egal ... nicht das Thema].

Wie ist das mit ini_set()? Ich denke mal, dass das nur fuer den aktuellen Prozess geaendert wird, sonst waers ja idiotisch ... richtig?
Alle anderen Prozesse, die ggf. gleichzeitig auf der selben Umgebung laufen, sind von diesem ini_set() nicht beeinflusst, korrekt?

Danke!

[Tom]

Hello,

Wie ist das mit ini_set()? Ich denke mal, dass das nur fuer den aktuellen Prozess geaendert wird, sonst waers ja idiotisch ... richtig?
Alle anderen Prozesse, die ggf. gleichzeitig auf der selben Umgebung laufen, sind von diesem ini_set() nicht beeinflusst, korrekt?

Das betrifft nur das Setting der Kopie im Speicher.
Andernfalls könnte das kein Provider von shared Hosts freigeben, weil dann ja immer irgendwie Alle betroffen sein könnten. Du musst es also leider in jedes Script einbauen, oder zumindest mit require_once() dazuladen.

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom

[dr.colossos]

Hi,

Das betrifft nur das Setting der Kopie im Speicher.
Andernfalls könnte das kein Provider von shared Hosts freigeben, weil dann ja immer irgendwie Alle betroffen sein könnten. Du musst es also leider in jedes Script einbauen, oder zumindest mit require_once() dazuladen.

Es lebe OOP, ich hab das in eine Klasse gepackt, und den Aufruf koennt ich einfach da rein packen, und es wuerde ueberall funktionieren, behaupt ich jetzt mal.

Danke

[Auge]

Hallo

Der interne verweist auf die eigene Domain, der externe auf eine Fremde.
PHÜ unterscheidet aber hier nicht nach Domain, sondern leider nach Scheme.

Dass extrerne Seiten nur mit Scheme angegeben werden können, ist ok, aber interne dürfen dies auch und dann hängt PHP da auch keine SID an, soweit ich das jetzt überschauen kann.

Wenn man das aber weiß, kann man so auch genau steuern, an welchen Links eine SID drangehängt werden kann.

Tschö, Auge

[Tom]

Hello,

Dass externe Seiten nur mit Scheme angegeben werden können, ist ok, aber interne dürfen dies auch und dann hängt PHP da auch keine SID an, soweit ich das jetzt überschauen kann.

Wenn man das aber weiß, kann man so auch genau steuern, an welchen Links eine SID drangehängt werden kann.

Ich schreibe aber oft vollqualifizierte URis, weil die Seiten dann auch offline und zerstückelt noch funktionieren. Das ist manchmal nötig.

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom

[Der Martin]

Hallo,

[*] Ein Leben ohne Möpse ist möglich, aber sinnlos.   [Loriot]
Laut Wikipedia heißt das Zitat aber etwas anders:
  „Ein Leben ohne Mops ist möglich – aber sinnlos!”   [Loriot]

ich habe, obwohl ich ein Fan von Loriot und seinem subtilen Humor bin, leider keine Audio- und/oder Videokonserve dieses Stücks zur Hand. Ich war nur aus der Erinnerung überzeugt, es hieße "ohne Möpse" im Plural. Das würde auch besser zu der für Loriot typischen Mehrdeutigkeit passen ...

Schönen Abend noch,
 Martin

[Tom]

Hello,

ich habe, obwohl ich ein Fan von Loriot und seinem subtilen Humor bin, leider keine Audio- und/oder Videokonserve dieses Stücks zur Hand. Ich war nur aus der Erinnerung überzeugt, es hieße "ohne Möpse" im Plural. Das würde auch besser zu der für Loriot typischen Mehrdeutigkeit passen ...

Ich habe noch eine uralte VHS-Kassette von ihm gefunden... "Ödipussi"

Un im Moment beginnt gerade seine langjährige Schauspiel-Partnerin auf N3 (Internetfernsehen *g*) mit "Adelheid und ihre Mörder" , die ja nun leider auch schon nicht mehr lebt...
Die beiden zusammen haben das immer gut gebracht!

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom

[Don P]

Hallo,

„Ein Leben ohne Mops ist möglich – aber sinnlos!”   [Loriot]

Klar, so ein Mops ist z.B. unverzichtbar zum Bildschirm reinigen!

Und ohne Möpse geht's natürlich erst recht nicht: entweder frau hat sie oder mann braucht sie...

Gruß, Don P

[Tom]

Hello,

„Ein Leben ohne Mops ist möglich – aber sinnlos!”   [Loriot]

*ROTFLL*

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom