DEFINE funktioniert nicht

[kuddeldaddeldu]

Hi,

DEFINE ist ja auf jeder seite verfügbar wenn es einmal definiert wurde...eine $_SESSION könnte man ja uU verlieren falls der user in der zwischenzeit an seinen cookies rumspielt....der inhalt/wert von DEFINE wird doch auf dem server gespeichert oder etwa auch in cookies beim client?

Wo hast Du denn diesen ausgemachten Blödsinn her (mal abgesehen davon, dass Du Konstanten meinst, define() ist eine Funktion zum Definieren ebensolcher)? Du solltest jetzt wirklich mal anfangen, das Manual zu benutzen. Lies das mal in Ruhe durch und dann überleg noch mal von vorne.
Das sind wirklich elementarste Grundlagen.

LG

[RamonaS]

Ja ok, an die letzten 2 Antworten....ich habe noch nie mit DEFINE gearbeitet, hab mich bisher auf $_SESSION verlassen....die sind aber futsch wenn keine cookies akzeptiert werden.

Ok ich lese das gleich, sofort und auf der stelle durch :-)
Danke.

[wahsaga]

hab mich bisher auf $_SESSION verlassen....die sind aber futsch wenn keine cookies akzeptiert werden.

Nein, auch das kann man so pauschal nicht sagen.

[RamonaS]

Du meinst bestimmt, das man die session id an die url anhängen kann in dem fall das cookies nicht gehen:

output_add_rewrite_var(session_name(),session_id()); 

Das mache ich aber nie, weil das in die hose gehen kann und die id von jedem übernommen werden kann.

Diehnt ja zur eigenen sicherheit des besuchers, die hat er im grunde erstmal nur, wenn er cookies zuläßt (die tun ja auch nicht weh :-)

[wahsaga]

Diehnt ja zur eigenen sicherheit des besuchers, die hat er im grunde erstmal nur, wenn er cookies zuläßt (die tun ja auch nicht weh :-)

Wenn du das als Grundvoraussetzung für die Nutzbarkeit der Site im vollen Umfang definierst - dann gibt es aber auch keinen Grund zu klagen, dass Sessions ohne Cookies nicht funktionieren würden.

[RamonaS]

Hallo,

>Wenn du das als Grundvoraussetzung für die Nutzbarkeit der Site im vollen Umfang definierst

Versteh ich jetzt nicht. Meinst du du würdest im notfall die session_id über $_GET und in form als hidden durch den äther schicken?

Also bei der "Grundvoraussetzung" da streiten sich doch die geister!? Ich würde da ersmal die dt. Sprache und die koordinierte-Mausführung auch voraussetzen :-) ...manche webseiten lassen sich sogar über TAB steuern...falls sie nicht hunderte fehler + warnungen haben und JS als grundvoraussetzung nehmen!

Nee, also ich halt von URIs mit 2m zahlensalatt nichts, das script weißt den besucher darauf hin, wenn er es nicht will dann eben nicht....wobei mindestens 95% aller user cookies aktiviert haben, weil sie nicht wissen was das genau ist oder wo man das abschaltet...die restlichen, like me, die wissen damit umzugehen und schalten die dann eventuell ein.

[wahsaga]

>Wenn du das als Grundvoraussetzung für die Nutzbarkeit der Site im vollen Umfang definierst

Versteh ich jetzt nicht. Meinst du du würdest im notfall die session_id über $_GET und in form als hidden durch den äther schicken?

Nein, ich meine, wenn du "keine Cookies - keine Session", und damit evtl. eingeschränkte Funktionalität in Kauf nimmst. Seite in vollem Umfang also nur mit Cookies nutzbar.


Und das nächste Mal, wenn du zitierst, ohne die [quote]-Tags zu nutzen, auf die ich dich nun schon mehrfach hingewiesen habe, schliess ich den betreffenden Thread.

[RamonaS]

[QUOTE=wahsaga;621372]Nein, ich meine, wenn du "keine Cookies - keine Session", und damit evtl. eingeschränkte Funktionalität in Kauf nimmst. Seite in vollem Umfang also nur mit Cookies nutzbar.


Und das nächste Mal, wenn du zitierst, ohne die

-Tags zu nutzen, auf die ich dich nun schon mehrfach hingewiesen habe, schliess ich den betreffenden Thread.

Yes sir, ich habe verstanden, Sir!

Das mußt du mir nochmal erklären: Wie kann ich ohne cookies erkennen, ob der besucher der eine 2te seite aufruft, immer noch der ist von der ersten?

Ich meine natürlich ohne POST-Daten umherzuschleifen und ohne 2m lange URLs

[wahsaga]

Das mußt du mir nochmal erklären: Wie kann ich ohne cookies erkennen, ob der besucher der eine 2te seite aufruft, immer noch der ist von der ersten?

Ich meine natürlich ohne POST-Daten umherzuschleifen und ohne 2m lange URLs

Im Zweifelsfalle, wenn du keine der gängigen Möglichkeiten nutzen willst - gar nicht.

Das war doch das, was ich bereits schrieb - auf bestimmte Funktionalität ggf. bewusst verzichten, wenn der "Preis" dafür zu hoch scheint.

[RamonaS]

Im Zweifelsfalle, wenn du keine der gängigen Möglichkeiten nutzen willst - gar nicht.

Das war doch das, was ich bereits schrieb - auf bestimmte Funktionalität ggf. bewusst verzichten, wenn der "Preis" dafür zu hoch scheint.

Sagens wir mal so: Als eizige "einigermassen sichere Möglichkeit" sehe ich nur den einsatz von cookies...der rest ist alls in meinen augen "gefährlich"...je weniger der besucher ahnung davon hat.

Stell die vor der loged sich bei so einem großen onlineshop ein...klickt sich dann dort durch die seiten durch...dann findet er zB ein artikel den er kaufen willl....nun schickt er den LINK aus der adressleiste seinem freund und frägt ihn ob zB dieser laptop für 399,- dort günstig ist.

So, nun hat dieser besucher aber seine cookies aus, und sendet seinem freund den link inclusive session_id....jetzt kann sein "guter Freund" dort in den shop rein, ist natürlich sofort angemeldet (er hat ja die session_id) und kann zB 50 laptops für seinen freund bestellen....was macht nu sein freund wenn 3 tage später ein LKW 50 laptops vor der haustür abladet? :-)

[fireweasel]

Sagens wir mal so: Als eizige "einigermassen sichere Möglichkeit" sehe ich nur den einsatz von cookies...

Für das von dir beschriebene Problem sind alle Methoden "sicher", die nicht die URL als Überbringer der Session-ID benutzen, also auch POST-Parameter (per versteckten Formularfeldern).

... So, nun hat dieser besucher aber seine cookies aus, und sendet seinem freund den link inclusive session_id....jetzt kann sein "guter Freund" dort in den shop rein, ist natürlich sofort angemeldet (er hat ja die session_id) ...

Um solche Angriffe abzuwehren gibts verschiedene Methoden. Die wichtigste ist, bei Bestellvorgängen am Schluss der Bestellung noch einmal die Zugangsdaten zu verlangen (Amazon macht das zum Beispiel so). Die kennt der "Hijacker" nämlich nicht, und damit kann er die Bestellung nicht abschicken.

Außerdem sollte jede Session ein(en) Timeout haben.

Zusätzlich kann man einen Teil der IP-Adresse des Nutzers überprüfen oder andere "Fingerabdrücke", die sein Browser so mitschickt. Das schließt zwar nicht komplett aus, dass ein Fremder mit einer kopierten ID die Session übernehmen kann, verringert aber zumindest die Wahrscheinlichkeit dafür.

Auch das regelmäßige Erneuern der Session-ID verringert die Gefahr der Weitergabe einer gültigen ID. Das gilt übrigens auch für Sessions per Cookie, weil man auch Session-Cookies relativ einfach stibitzen kann. Allerdings weiß ich nicht, ob die entsprechende Funktion session_regenerate_id() mittlerweile ordentlich funktioniert.

[combie]

Allerdings weiß ich nicht, ob die entsprechende Funktion session_regenerate_id() mittlerweile ordentlich funktioniert.

Aber ich!! Sie funktioniert (und das seit dem ersten Tag).

Allerdings kann es bei ungeschickter Anwendung zu Race Conditions kommen. Aber das ist kein Problem des Regenerate selber, sondern ehr eine Eigenschaft des HTTP.

[piratos]

Aber ja doch oder nicht ?

This function is very problematic when used in conjunction with either relatively quick browser refreshes or when you've even got another included element on the page (e.g., an image) included on the page which also regenerates the id! (The effect is that you'll lose all session data and it will look like you session data didn't get persisted).

The Zend Framework Session classes uses session_regenerate_id(), I would suggest that you comment out the line in Zend/Session.php which calls session_regenerate_id() (there is only one at the time of writing this).

I'm not aware of any option to turn it off in Zend_Session.

Mehr davon hier: PHP: session_regenerate_id - Manual

und noch mehr davon durch googlen.

[fireweasel]

Aber ich!! Sie funktioniert (und das seit dem ersten Tag).

Dein fast religiöser Optimismus in allen Ehren, aber es gab ein PHP vor der Version 5.1.0, auch wenn das schon ein paar Jährchen her ist.

http://forum.de.selfhtml.org/archiv/...37614/#m894038

Allerdings kann es bei ungeschickter Anwendung zu Race Conditions kommen. Aber das ist kein Problem des Regenerate selber, sondern ehr eine Eigenschaft des HTTP.

Mehr Info?

Ich dachte eher an die Probleme mit dem Verlust der Session, wenn jemand ohne Cookies gleichzeitig mehrere Browser-Fenster (oder Tabs) der gleichen Website geöffnet hat.

[combie]

Das hat nichts mit Religion zu tun!
Einfach mal kundig machen, dann wirst du das auch einsehen!

Dass irgendwann ein Parameter hinzugefügt wurde, heißt nicht, dass es vorher nicht funktioniert hat. Es ist jetzt allerdings mit Parameter meist sinnvoller, da gebe ich dir recht.
Es wurde also kein Bug behoben, sondern nur ein optionales Feature hinzugefügt.

Ich dachte eher an die Probleme mit dem Verlust der Session, wenn jemand ohne Cookies gleichzeitig mehrere Browser-Fenster (oder Tabs) der gleichen Website geöffnet hat.

Ja und nein!
Mit session.use_trans_sid ist regenerate weiterhin wenig brauchbar. Daran hat sich nichts geändert und daran wird sich nichts ändern. Aber eigentlich bringt es da nur das generelle transsid Problem in den Vordergrund. Ist also auch kein Fehler des Regenerate().

Auch Mit session.use_cookies_only kann es RaceConditions geben. Und das liegt an den HTTP Eigenschaften. Da beißt keine Maus einen Faden ab. Das Problem ist auch nicht wirklich in den Griff zu bekommen.

Sessionlocking/RaceCondition Test:

In die folgenden Frames sollten die Zeiten im 2 Sekunden Takt tröpfeln. Die Hits sollten fortlaufend kommen. Dabei ist die Reihenfolge, in der die Frames gefüllt werden vom Browser/Router/Gateway/Proxy bestimmt und kann sich durchaus ändern.

Auch die unerwünschten Seiteneffekte von session_regenerate_id() lassen sich damit schön vorführen.

<?php
error_reporting(-1);
ini_set('display_errors',TRUE);

session_start();

//session_regenerate_id(); // erzeugt Race Conditions
//session_regenerate_id(TRUE); // erzeugt Race Conditions und Fehlermeldungen

sleep(2);

if(isset($_GET['frame']))
{
  ++$_SESSION['hitcounter'];
  echo 'Zeit: '. (time() - $_SESSION['richtzeit']) .'<br>';
  echo 'Hits: '. $_SESSION['hitcounter'] .'<br>';
  exit;
}

$_SESSION['richtzeit']  = time();
$_SESSION['hitcounter'] = 0;

?>
<frameset rows="20%,20%,20%,20%,20%">
  <frame src="?frame=<?php echo mt_rand()?>" name="test1">
  <frame src="?frame=<?php echo mt_rand()?>" name="test2">
  <frame src="?frame=<?php echo mt_rand()?>" name="test3">
  <frame src="?frame=<?php echo mt_rand()?>" name="test4">
  <frame src="?frame=<?php echo mt_rand()?>" name="test5">
</frameset>