session_id

[friction]

hallo,

Mir ist aufgefallen, dass meine $_SESSION  nicht bei abgeschalteten COOKIES funktioniert.

Ich habe gelesen, dass es an der session_id liegt die jedesmal neu generiert wird, oder ?

1. muss ich um 100%iges funktionieren meiner $_SESSION zu gewährleisten, auf jeder seite meine session_id() aufrufen und sie per GET an die url anhängen.

2. Gibts eine Möglichkeit die session_id automatisch an die url hinzuzufügen ?

3. Was muss ich noch beachten.

danke

fric

[Gerhard]

So ein Zufall dass du soeben einen Session-Thread eröffnet hast.
Kennt vielleicht jemand ein gutes Session-Einsteiger Tutorial aus eigener Erfahrung? Auf google hab ich noch nicht das gefunden was ich brauche. Ich würde gerne ein kleines Login-Skript realisieren, habe aber zuvor noch nicht mit Sessions gearbeitet.
Danke im Voraus
lg Gerhard

[Sven Rautenberg]

Moin!

Kennt vielleicht jemand ein gutes Session-Einsteiger Tutorial aus eigener Erfahrung?

Nein, mir ist keins bekannt. Vielleicht hilft Google.

Ich würde gerne ein kleines Login-Skript realisieren, habe aber zuvor noch nicht mit Sessions gearbeitet.

Die Anwendung von Sessions ist denkbar simpel:
1. Du startest in jedem Skript direkt zu Beginn mit session_start() die Session. Dieser Befehl muß kommen, noch bevor irgendein Zeichen HTML-Text (auch kein Leerzeichen vor dem ersten "<?") ausgegeben wird.

2. Die gestartete Session stellt dir dann ein Array namens $_SESSION zur Verfügung, in das du beliebige Werte speichern kannst:
$_SESSION['wetter_von_heute']="sonnig";
$_SESSION['temperaturen']['morgens']=18;
$_SESSION['temperaturen']['mittags']=22;
$_SESSION['temperaturen']['abends']=20;
$_SESSION['regenmenge'][1]="10 mm";

Der Session-Mechanismus stellt sicher, dass dieses Array abgespeichert und beim nächsten Skriptaufruf mit derselben Session-ID im zuletzt gespeicherten Zustand wiederhergestellt wird.

- Sven Rautenberg

[Gerhard]

Und wozu dient die Übergabe der Session-ID per QueryString?
Wofür benötigt man diese dann im nächsten Skript?
lg gerhard

[Daniel]

Ahoi Gerhard,

Und wozu dient die Übergabe der Session-ID per QueryString?
Wofür benötigt man diese dann im nächsten Skript?

Du willst ja ein login script machen. also gibt der/die/das Benutzer/in
sein pwd und benutzername an. wenn er sich erfolgreich eingeloggt hast
musst du, bzw das $_SESSION-array sich dies merken. damit du dann auf
den geschützten seiten kucken kansnt ob der/die/das Benutzer/in
eingeloggt ist benötigst du die session_id um auf das $_SESSION-array
dieses Users zuzugreifen.

MfG

[Sven Rautenberg]

Moin!

Und wozu dient die Übergabe der Session-ID per QueryString?
Wofür benötigt man diese dann im nächsten Skript?

Man selbst benötigt die gar nicht, aber der Session-Mechanismus, denn der kann sowohl Cookies als auch die URL zur Weitergabe der Session-ID benutzen, ohne dass du dich darum genau kümmern mußt.

- Sven Rautenberg

[Tom]

Hello,

Und wozu dient die Übergabe der Session-ID per QueryString?
Wofür benötigt man diese dann im nächsten Skript?

Dazu passt eigentlich ganz gut mein Thread von gestern, in dem ich nach einem HTTP-Sniffer fragte...

http://web-sniffer.net/

Wenn Du mit Sessions erst beginnst:

1. alle Fehlermeldungen anschalten für die Scripte, Ausgabe aber in eine Datei umleiten
2. Am Browser Cookies erst nach Rückfrage annehmen, dann kann man vorher reingucken
3. Öfter mal mit dem HTTP-Sniffer die gebauten Seiten ansehen, was sie in den
   HTTP-Headern senden
4. Bau Dir ein Script, was mit getallheaders() den Request vom Browser anzeigen kann

<?php ### headers.php ###

$_headers = getallheaders();

echo "<pre>";
  print_r($_headers);

echo "<hr>POST<br />\n";
  print_r($_POST);

echo "<hr>REQUEST<br />\n";
  print_r($_REQUEST);

echo "</pre>";
?>

...nur so als Beispiel.

Und dann spiel einfach rum mit GET, POST, COOKIE und $_SESSION

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Maulwurf]

Hi,

hier hast Du etwas http://aktuell.de.selfhtml.org/tippstricks/php/loginsystem/index.htm

Gruss

Maulwurf

[Gerhard]

So ich bin jetzt eigentlich durch probieren schon ziemlich weit.
Danke für die guten Tipps.
Was mich noch interessieren würde: Wann verfällt eine Session von alleine? Wenn ein User sich einmal einloggt und eine Woche später wieder kommt dann ist die Session doch weg oder?

Und könnte mal jemand nachschauen ob das jetzt so ungefähr sicher ist?
--------------
login.htm
--------------
<html>
<body>
<form name="login" action="check.php" method="post">
  <input type="text" name="user">
  <input type="password" name="passwort">
  <input type="submit" name="submit">
</form>
</body>
</html>

--------------
check.php
--------------
<?
  session_start();
  $vUser=$_REQUEST['user'];
  $vPasswort=$_REQUEST['passwort'];
  if($vUser=="Gerhard"&&$vPasswort=="hallo")
  {
    $_SESSION["user"]=$vUser;
    $_SESSION["passwort"]=$vPasswort;
    header("Location: geheim.php");
  }
  else
  {
    echo "Falsche Angaben";
    session_destroy();
  }
?>

------------
geheim.php
------------
<?
  session_start();
  if(isset($_SESSION["user"])&&isset($_SESSION["passwort"]))
  {
    if($_SESSION["user"]=="Gerhard"&&$_SESSION["passwort"]=="hallo")
      echo "Erlaubt";
    else
      echo "access denied";
  }
  else
    echo "access denied";
?>

Danke nochmal
lg Gerhard

[Tom]

Hello,

<?
  session_start();

$vUser=$_REQUEST['user'];
  $vPasswort=$_REQUEST['passwort'];

Warum verwendest Du hier $_REQUEST und nicht $_POST?

if($vUser=="Gerhard"&&$vPasswort=="hallo")
  {
    $_SESSION["user"]=$vUser;
    $_SESSION["passwort"]=$vPasswort;
    header("Location: geheim.php");
  }
  else
  {
    echo "Falsche Angaben";
    session_destroy();
  }
?>

---

geheim.php

<?
  session_start();
  if(isset($_SESSION["user"])&&isset($_SESSION["passwort"]))
  {
    if($_SESSION["user"]=="Gerhard"&&$_SESSION["passwort"]=="hallo")

Naja, in groben Zügen schon so möglich.

allerdings sollte da eine Funktion stehen, die sich aus der Session

die Daten holt und dann in einer DB mit den aktuellen Zugangsdaten vergleicht.

_Jedes_ Mal. Denn sonst könntest Du den User _während_ einer Session nicht

sperren.

echo "Erlaubt";
    else
      echo "access denied";
  }
  else
    echo "access denied";
?>

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Gerhard]

Warum verwendest Du hier $_REQUEST und nicht $_POST?

Stimmt, hier werde ich post nehmen.

Naja, in groben Zügen schon so möglich.

allerdings sollte da eine Funktion stehen, die sich aus der Session

die Daten holt und dann in einer DB mit den aktuellen Zugangsdaten vergleicht.

_Jedes_ Mal. Denn sonst könntest Du den User _während_ einer Session nicht

sperren.

Ja das weiß ich, ich hab nur jetzt zum Austesten mal hardcodierte Daten genommen.
Wie kann man einen User überhaupt während einer Session sperren?
lg Gerhard

[Daniel]

Ahoi Gerhard,

Wie kann man einen User überhaupt während einer Session sperren?

in dem du in der tabelle eine spalte beim benutzer hinzufügst, z.B. mit
dem namen "gesperrt". als value 0 (nicht gesperrt) und 1 (gesperrt) dann
holst du dir den wert in der spalte, bevor du was ausgibst,

if 1 then kick

MfG

[Tom]

Hello,

Wie kann man einen User überhaupt während einer Session sperren?

Indem man z.B. bei der Anmeldung des Users folgendermaßen vorgeht:

Die aktuelle Sessionnummer nehmen
  Die Userdaten nehmen
  in einer Usertabelle (DB) nachschauen, für welche Scripte der User eine Berechtigung hat
  wenn Berechtigungen vorliegen, einen datensatz erzeugen in der Login-Tabelle mit
    - Sessionnummer
    - Usernummer
    - Loginzeit
    - Letzter Zugriff
    - Enabled - Flag  (kann auch ein Int sein z.B.: 0 = disabled, 1 = revalidate, 2 = validated)

Wenn der User nun seine Session fortsetzt, kann man in jedem Script erstmal schauen,
  ob überhaupt eine Session besteht, die in der Tabelle eingetragen ist

Wenn Du den User loswerden willst, kannst Du einfach die Bedingugnen ändern...

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Daniel]

Ahoi Gerhard,

Was mich noch interessieren würde: Wann verfällt eine Session von alleine?

das kommt auf die einstellungen des Servers an. das kann man so pauschal nicht sagen.

Und könnte mal jemand nachschauen ob das jetzt so ungefähr sicher ist?

ja sicher kann man nachschaun.

---

login.htm

...

---

check.php

<?
  session_start();
  $vUser=$_REQUEST['user'];
  $vPasswort=$_REQUEST['passwort'];

Warum reauest wenn du post machst?

if($vUser=="Gerhard"&&$vPasswort=="hallo")

benutzername und pwd sollten nie im klartext im code stehen. lager das
pwd und den benutzernamen aus. in eine seperate datei außerhalb des
root-verzeichnisses oder in einen unterordern der mit htaccess
geschützt ist und alle http anfragen blockt.

{
    $_SESSION["user"]=$vUser;
    $_SESSION["passwort"]=$vPasswort;

warum nicht $_SESSION["login"]=true;?

header("Location: geheim.php");
  }
  else
  {
    echo "Falsche Angaben";
    session_destroy();

^^ merk dair das für den logout button damit sich keiner als der user mit der SID welches durch das einloggen als geauthet gillt einschmuggeln kann. daher empfiehlt es sich auch immer den logout-button zu benutzten.

}
?>

---

geheim.php

...

sieht für den anfang schonmal gut aus. evt soltlest du aber mit === prüfen anstatt mit ==. des weiteren das pwd mit md5() verschlüsseln. wenn es denn unbedingt im code stehen muss. sprich du machst ein kleines script

<form method="post">
<input type="text" name="wort">
<input type="submit">
<?
if(isset($_POST['wort']))
{
  echo md5($_POST['wort']);
}
?>

ist jetzt stark geraft. das was dir dann ausgegeben wird speicherst du im code:
$true_pwd = "dein md5 codiertes PWD";

und wandelst das eingegebene auch per md5() um und prüfst beide mit ===
MfG

[Gerhard]

=== ? Das sehe ich heute zum ersten Mal. Was wird dabei anders gemacht als bei ==?
Wie bereits gesagt, ich habe die Userdaten nur zu Testzwecken hardcodiert, später werde ich dann natürlich eine User-Tabelle in meiner Datenbank verwenden.
lg Gerhard

[Daniel]

Ahoi Gerhard,

=== ? Das sehe ich heute zum ersten Mal. Was wird dabei anders gemacht als bei ==?

if( 1 == "1" ) => true
if( 1 === "1" ) => false

bei === wird auch der TYP noch mitüberprüft AFAIK, hoffe hab mich nicht falsch ausgedrückt.

Wie bereits gesagt, ich habe die Userdaten nur zu Testzwecken hardcodiert, später werde ich dann natürlich eine User-Tabelle in meiner Datenbank verwenden.

und die zugangsdaten für die DB? direkt im code drin? wenn ja gilt dort
das gleiche, außer das du mit md5() dort nicht weit kommst. da hilft nur
außerhalb des roots oder unterverzeichniss mit .htaccess (DENIE FROM ALL)

MfG

[Gerhard]

Ok jetz weiß ich alles was ich (derzeit) brauche.
Danke vielmals für die fachkundige und schnelle Hilfe
lg Gerhard

[Tom]

Hello,

warum nicht $_SESSION["login"]=true;?

Weil die Überprüfung dann nur zu Beginn der Session stattfinden würde, und nicht dynamisch mit jedem Request. Hier sollte daher man einen indirekten Aufruf setzen, also z.B. die Sessionnummer nehmen, und in einer DB nachschauen, ob sie noch berechtigt ist und welche Berechtigungen für den User vorliegen.

Wenn man das bei jedem Zugriff macht, hat man auch gleich das beliebte "Wer ist Online?" erledigt.

Update LOGIN
set lastclick = now()
where session\_nr = '$session_nr' and
      now() - lastclick > $maxtime and
      enabled = 1

oder so ähnlich

Und wenn das Update erfolgreich war, ist der User noch angemeldet, die Session ist noch gültig und man kann nun aus der Usertabelle die aktuellen Rechte für da jeweilige Script (oder Include) heraussuchen.

So baut man sich schnell eine Userverwaltung für komplexeste Anwendungen auf.

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Daniel]

Ahoi Tom,

warum nicht $_SESSION["login"]=true;?
Hier sollte daher man einen indirekten Aufruf setzen, also z.B. die Sessionnummer nehmen, und in einer DB nachschauen, ob sie noch berechtigt ist und welche Berechtigungen für den User vorliegen.

deshalb hab ich als auch ein $_SESSION['login'] und $_SESSION['user_id']

MfG

[Tom]

Hello,

warum nicht $_SESSION["login"]=true;?
Hier sollte daher man einen indirekten Aufruf setzen, also z.B. die Sessionnummer nehmen, und in einer DB nachschauen, ob sie noch berechtigt ist und welche Berechtigungen für den User vorliegen.

deshalb hab ich als auch ein $_SESSION['login'] und $_SESSION['user_id']

Nö, falsch verstanden.
An die Sessiondatei kommt unter Normaumständen nur der berechtigte Prozess heran.
Es handelt sich dabei ja nur um einen transienten Speicher für einen Client-Server-Prozess.
Der Admin weiß also gar nicht, welcher User gerade welche Sessionnummer hat.

An eine DB kommt aber auch der Admin heran. Wenn der Prozess (das Script) die Sessionnummer nun in der DB einträgt, kann der Admin auch gelich dort die Berechtigungen ändern und beim nächsten Request haben die bereits Auswirkugnen, und nicht erst beim nächsten "Login".

Darum gehören Logindaten nicht in die Session.

Außerdem sind Sessiondaten flüchtig. Die DB kann man aber so organisieren, dass sie gleich für Historie und Logbuch dienen kann.

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Daniel]

Ahoi Tom,

deshalb hab ich als auch ein $_SESSION['login'] und $_SESSION['user_id']

ich glaube wir reden aneinander vorbei, ich habe eine login.php. dort
wird bei übereinstimmung der daten $_SESSION['login'] und
$_SESSION['user_id'] entsprechend gesetzt. die user_id hab ich ja da
ich in der DB war und nach pwd und benutznamen überneinstimmung
gesucht habe. auf jeder folge seite habe ich nun eine funktion welche
überprüft ob $_SESSION['login'] existiert und true ist. wenn nicht
wird auf die loginseite weitergeleitet und das script mit die;
beendet. ansonsten ist der user schonmal eingeloogt, nun will ich
natürlich wissen wer das ist und ob er das benötigte recht hat dieses
script aufzurufen, das machst diese funktion ebenfalls. diese nimmt
die user_id und schaut in der DB nach ob der user gespeert ist, wenn
nicht ob er das recht hat und sollte er gespert sein gibts ein
session_destroy(); die; und wenn er das recht nicht hat kommt er auf
die main-page. deshalb eben die user_id und eingeloggt. in die tabelle
noch ein status alla last_action zu machen ist ja kein hexenwerk.
außerdem hab ich dann ja die user_id und so kann man das recht leicht
bewerkstelligen das der user sein pwd ändern kann, und zwar nur seins.

MfG

[Tom]

Hello MfG,

deshalb hab ich als auch ein $_SESSION['login'] und $_SESSION['user_id']

[...]

... und das ist unsicher.
Da sowieso in der DB nachgeschaut werden muss, ob der User Rechte hat, kann man auch gleich dort nachschauen, ob er angelmeldet ist.

Anderenfalls könnte ich als Mitnutzer einfach quer über den Server mal eben Deine Sessiondateien scannen und meine derart verändern, dass da ein "login==true" drinsteht. Und eine passende Usernummer mit genügend hohen Rechten finde ich dann auch noch.

Dass das bei vielen Providern immer noch geht, habe ich in einem anderen Thread schon erwähnt.

Also sollte man die Zugangsrechte nur in der Datenbank halten und auch nicht in der Session abspeichern, sondern immer nur in einer (flüchtigen) Scriptvariable. Die ist einfach besser geschützt.

Sessiondateien sind oft für alle User eines Shared Hosts erreichbar, da PHP für alle User mit derselben Userkennung arbeitet. Das Problem entfällt, wenn PHP und _alle_ VirtHosts, für die es arbeiten soll, sauber eingerichtet sind oder wenn man gleich die CGI-Variante benutzt. Die ist aber wesentlich langsamer, da immer erst ein komplettes "PHP-Kernel" geladen werden muss, während in der Modul-Variante immer nur eine Instanz der bereits im Speicher befindlichen erzeugt wird.

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Daniel]

Ahoi Tom,

Anderenfalls könnte ich als Mitnutzer einfach quer über den Server mal eben Deine Sessiondateien scannen und meine derart verändern, dass da ein "login==true" drinsteht.

wie geht denn das? ich benutze keine cookies.
und über die Session_id kann man sich bei deinem verfahren leicht
einklinken weil du diese nimmst und in der DB schaust ob die
eingeloggt ist. das ist auch nicht sicherer.

Naja sicherheit ist ein wichtiger punkt. sollte ich grad tomaten auf den
augen haben lass ich mich von dir etwas besseren belehren und etwas
ausführlichere erläuterung der sicherheitslücke wäre nicht schlecht.

MfG

[Tom]

Hello,

Was mich noch interessieren würde: Wann verfällt eine Session von alleine? Wenn ein User sich einmal einloggt und eine Woche später wieder kommt dann ist die Session doch weg oder?

Die Sessionverwaltung von PHP kümmert sich nicht um die Gültigkeit einer Session.
Das musst Du selber programmieren.
PHP als solches kümmert sich nur "gelegentlich" um das Löschen von länger nicht benutzten Sessiondateien, damit die nicht die Platte zumüllen. Die Mindest-nicht-mehr-benutzt-dauer dieser Dateien stellt man mit session.gc_maxlifetime ein und mit den Paramtern

session.gc_divisor      1000        1000
session.gc_probability    1           1

Wenn der GC (Der Müllsammler) richtig eingerichtet ist, räumt er die Dateien weg. Da es aber nur ein PHP auf einem Server gibt, räumt er die Dateien aller User und Domains auf, die er erreichen kann. Liegen die nun alle in /tmp, und ein User fummelt an den Einstellungen so herum, dass die Lebensdauer nur noch 1 sec beträgt, sind aller Sekunde alle Sessiondateien verschwunden, obwohl die Sessions (der Vorgang als solcher) noch gar nicht beendet sind.

Lege also Deine Sessiondatein als erstes in ein eigenes Verzeichnis. Wenn Du keinen Serverzugang hast, geht das z.B. in einem    Domain/.ht_sessions/  Verzeichnis. Allerdings kann es sein, dass der GC das dann nicht mehr aufräumt, zumindest bei älteren PHP-Versionen, da ihm der absolute Pfad zu lang wird.

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Tom]

Hello,

es gibt zum Thema Sessions einen ausführlichen Manualbereich

http://de.php.net/session

Und dann solltest Du Dir die von phpinfo()
http://de.php.net/manual/de/function.phpinfo.php
http://de.php.net/manual/en/ini.php#ini.list
bereitgestellten Einstellungen für session.xxxxxx ansehen.

Beispiel:

Directive             Local Value Master Value
session.auto_start       Off         Off
session.bug_compat_42    Off         Off
session.bug_compat_warn  On          On
session.cache_expire     180         180
session.cache_limiter  nocache     nocache
session.cookie_domain  no value    no value
session.cookie_lifetime   0           0
session.cookie_path       /           /
session.cookie_secure   Off          Off
session.entropy_file   no value    no value
session.entropy_length    0           0
session.gc_divisor      1000        1000
session.gc_maxlifetime  1440        1440
session.gc_probability    1           1
session.name           MEINNAME    PHPSESSID
session.referer_check  no value    no value
session.save_handler    files       files
session.save_path    session/domain  /tmp
session.serialize_handler php        php
session.use_cookies      On          On
session.use_only_cookies Off        Off
session.use_trans_sid    Off        Off

Bevor Du nicht die Bedeutung jeder einzelnen Einstellung erlesen hast, lohnt sich ein weiterposten kaum. Das wird dann noch genug Fragen aufwerfen... ;-)

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Sven Rautenberg]

Moin!

Mir ist aufgefallen, dass meine $_SESSION  nicht bei abgeschalteten COOKIES funktioniert.

Dann ist die Fallback-Methode in deiner PHP-Version ausgeschaltet.

Ich habe gelesen, dass es an der session_id liegt die jedesmal neu generiert wird, oder ?

Falschrum. Weil dein Browser keine Cookies akzeptiert und die Session-ID auch nicht in der URL übermittelt wird, wird bei jedem Seitenaufruf eine neue ID generiert.

1. muss ich um 100%iges funktionieren meiner $_SESSION zu gewährleisten, auf jeder seite meine session_id() aufrufen und sie per GET an die url anhängen.

Es gibt die Konstante SID, welche für den Fall, dass bislang kein Cookie mit Session-ID festgestellt wurde, die Zeichenkette aus session_name()."=".session_id() enthält, welche direkt als Parameter an jede URL angehängt werden kann (mit Fragezeichen oder Und-Zeichen, je nach Bedarf).

Formulare müssen natürlich auch passend behandelt werden, indem man ein hidden-Feld hinzufügt, dessen Namen mit session_name() und dessen Value mit session_id() ausgefüllt wird.

Würdest du den Automatismus von PHP nutzen, könntest du dir diese Arbeit sparen.

2. Gibts eine Möglichkeit die session_id automatisch an die url hinzuzufügen ?

session.use_trans_sid in der PHP.ini

3. Was muss ich noch beachten.

Nix.

- Sven Rautenberg

[friction]

hallo,

Formulare müssen natürlich auch passend behandelt werden, indem man ein hidden-Feld hinzufügt, dessen Namen mit session_name() und dessen Value mit session_id() ausgefüllt wird.

bei den formularen muss ich aber nach der action="$path?PHPSESSID=$sessid" hinzufügen, weil all meine formulare per POST versendet werden.

oder erkennt PHP die PHPSESSID auch im $_POST array , wenn ich hidden felder benutze ?

gruß

fric

[Sven Rautenberg]

Moin!

bei den formularen muss ich aber nach der action="$path?PHPSESSID=$sessid" hinzufügen, weil all meine formulare per POST versendet werden.

oder erkennt PHP die PHPSESSID auch im $_POST array , wenn ich hidden felder benutze ?

PHP selbst fügt Hidden-Felder hinzu, wenn die Automatik an ist. Und was da drin steht (gehe nicht vom festen String "PHPSESSID" aus, dieser Wert kann sowohl von dir als auch vom Provider beliebig geändert werden - der korrekte, aktuelle String wird von session_name() ausgegeben), hatte ich ja schon geschrieben.

- Sven Rautenberg

[wahsaga]

hi,

bei den formularen muss ich aber nach der action="$path?PHPSESSID=$sessid" hinzufügen, weil all meine formulare per POST versendet werden.

oder erkennt PHP die PHPSESSID auch im $_POST array , wenn ich hidden felder benutze ?

ja, verflixt noch mal.

warum spielt eigentlich jemand mit sessions herum, der davon so wenig ahnung hat, und offenbar auch nicht in der lage ist, sich im manual oder anderen quellen mal über deren funktionsweise zu informieren?

gruß,
wahsaga

[Tom]

Hello,

warum spielt eigentlich jemand mit sessions herum, der davon so wenig ahnung hat, und offenbar auch nicht in der lage ist, sich im manual oder anderen quellen mal über deren funktionsweise zu informieren?

Nun schimpf doch nicht.
Wir erzählen ihm doch gerade in kleinen überschaubaren Paketen, was Sessions überhaupt sind, wie die funktionieren, und als nächstes werden wir ihm sagen, dass das Vorhandensein einer Sessionkennung nichts mit einem "Login" zu tun hat. Allerdings setzt ein "Login" i.d.R. auf einem Sessionmechanismus auf, benötigt ihn also, um das "Login" zu verwalten.

"Login" steht in Häkchen, weil es das bei HTTP eigentlich gar nicht gibt. Es handelt sich bei jedem Request um ein Wiederaufsetzen, also ein "Reconnect" auf den letzten Zustand vor der Response.

Also muss das "Loginverfahren" bei jedem Request vollständig durchlaufen werden, allerdings ohne das Erfragen der Zugangsdaten, wenn die schon übermittelt wurden.

... to be continued ...

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[friction]

hallooooooo,

warum spielt eigentlich jemand mit sessions herum, der davon so wenig ahnung hat, und offenbar auch nicht in der lage ist, sich im manual oder anderen quellen mal über deren funktionsweise zu informieren?

bitte nicht so aufregen !

1. habe ich mich schon über sessions schlau gemacht, habe aber einfach nocht nicht ganz den überblick und stehe zeitlich unter druck.

2. du brauchst ja nicht zu antworten wenn dich meine fragen nerven , das ist schließ ein forum, und sinn eines forums ist es fragen zu stellen wenn man einproblem hat.

danke

und schönen tag noch :-)

[Tom]

Hello,

1. habe ich mich schon über sessions schlau gemacht, habe aber einfach nocht nicht ganz den überblick und stehe zeitlich unter druck.

Dann solltest Du dich aber auch nicht mit einer so sicherheitsrelevanten Materie beschäftigen. Dafür braucht man Zeit und muss diverse eigene Gehversuche machen.
Ohne Übung kommt dabei nachher nur Mist heraus.

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[friction]

Hello,

Dann solltest Du dich aber auch nicht mit einer so sicherheitsrelevanten Materie beschäftigen. Dafür braucht man Zeit und muss diverse eigene Gehversuche machen.
Ohne Übung kommt dabei nachher nur Mist heraus.

du hast 100 %ig recht :-)

aber kannst du das mal meinem Chef sagen :-)

Ihr wisst dich wie die sind.

no time:-)

werde mein wissen aber natürlich vertiefen!

gruß

friction

[Tom]

Hello,

bei den formularen muss ich aber nach der action="$path?PHPSESSID=$sessid" hinzufügen, weil all meine formulare per POST versendet werden.

Dieser Parameter würde dann im $_GET-Array landen

oder erkennt PHP die PHPSESSID auch im $_POST array , wenn ich hidden felder benutze ?

PHP wertet die übertragenen Paramter nach der festgelegten reihenfolge aus.
Normal ist GPC, also GET, POST, COOKIE

Letzter Parameter überschreibt dann die vorigen, sofern vorhanden und Überschreiben in Frage kommt.
Bei den Sessions wird mit abgeschalteter Register-Globals genau andersherum gesucht: Gibt es einen Cookie unter dem Sessionnamen, wird der benutzt und die Suche wird abgebrochen, sonst wird nach einem Post-Paramter gesucht, ist der vorhanden, wird die Suche abgebrochen... Zuletzt wird der Get-Parameter ausgewertet.

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Sven Rautenberg]

Moin!

PHP wertet die übertragenen Paramter nach der festgelegten reihenfolge aus.
Normal ist GPC, also GET, POST, COOKIE

So landen die Werte auch in $_REQUEST.

Letzter Parameter überschreibt dann die vorigen, sofern vorhanden und Überschreiben in Frage kommt.

Du meinst, ein Parameter, der im Cookie steht, überschreibt den gleichnamigen in POST und GET.

Bei den Sessions wird mit abgeschalteter Register-Globals genau andersherum gesucht:

Nein, da wird nicht "andersrum" gesucht. Man kann doch einfach in $_REQUEST nachsehen, was als Eintrag für die Session-ID angekommen ist - gemäß der Sortierlogik oben wäre das dann bei Existenz eines Cookies in jedem Fall der Cookie, und nicht die Werte aus POST oder GET. Das hat auch nichts mit register_globals zu tun.

Ich würde aber behaupten, dass der Session-Mechanismus sich eigentlich nicht um irgendeine Reihenfolge "gpc" kümmert, sondern unabhängig davon Cookies, GET und POST auswertet. Auch wieder unabhängig von irgendwelchen register_globals.

- Sven Rautenberg

[Tom]

Hello,

Du meinst, ein Parameter, der im Cookie steht, überschreibt den gleichnamigen in POST und GET.

den gleichnamigen _aus_ Post oder Get. Nicht das das nun durcheinanderkommt ;-)

Ich würde aber behaupten, dass der Session-Mechanismus sich eigentlich nicht um irgendeine Reihenfolge "gpc" kümmert, sondern unabhängig davon Cookies, GET und POST auswertet. Auch wieder unabhängig von irgendwelchen register_globals.

Das hängt von der PHP-Version ab. Wir hatten hier neulich so eine Merkwürdigkeit, die keiner so richtig erklären konnte. Das war ein Bug. Prinzipiell ist aber seit 4.3.3. die Sache wohl repariert.

Harzliche Grüße aus http://www.annerschbarrich.de

Tom