Announcement

**Christian Marquardt** · 17.02.2009, 07:57

ja, das ist so. Es werden direkt keine Variablen angelegt, sondern das Script (die Scripte insgesamt) läuft im Server "mehrfach", so das jeder User "sein eigenes" Script hat

**necrid** · 18.02.2009, 12:44

also in dem fall hat dann auch jeder user seine eigenen $variablen ?

wenn das so ist bin ich ja erleichtert.

dachte schon ich müsste alles mit session variablen machen .... ohjeh

dann schonmal vielen dank für deine antwort.

**Arne Drews** · 26.02.2009, 22:40

@necrid:
Wenn es nicht so einfache Dinge, wie Formulare sind, sondern eher in Richtung Benutzeroberfläche geht,
ist die Wahl der Sessions aber zu empfehlen!
Dann solltest Du Dich damit befassen...

**Christian Marquardt** · 27.02.2009, 07:46

Was ist der Unterschied zwischen einem Formular und einer "Benutzeroberfläche"?

Wozu brauche ich bei Letzerem zwingend Sessionvariablen?

**Falk Prüfer** · 27.02.2009, 10:24

Hallo,

mal so zum Verständniss bevor lange Diskussionen ausbrechen einen langen Artikel

.
Variablen in PHP - egal ob nun lokal oder global definiert - existieren immer nur solange, wie das aktuell aufgerufene Script läuft. Bei jeder Aktion die die Kontrolle an den Browser zurückgibt (Scriptende, externe Weiterleitung) sind die Inhalte dieser Variablen vergessen. Der nächste Scriptaufruf kann nicht mehr auf die alten Inhalte zurückgreifen - wie auch.
Um nun Variableninhalte von einem Script an das nächste weiterzureichen gibt es prinzipiell drei Möglichkeiten. Entweder ich reiche sie per POST- bzw. GET-Parameter von Script zu Script weiter, speichere sie in einem COOKIE oder in einer s.g. SESSION.

Jede Variante hat ihre Vor- und Nachteile.

Die Nachteile von Variante 1 liegen auf der Hand. Ab einer bestimmten Anzahl Parameter werden (bei GET) die URLs unendlich lang und sind naturgemäß sehr leicht zu manipulieren. Bei Verwendung von POST wird der Manipulationsafufwand zwar etwas größer, die langen URLs fallen weg aber das Handling wird natürlich auch um einiges schwieriger. Der einzige Vorteil liegt in der Einfachheit.
Variante 1 kann man also überall dort verwenden, wo wenige, irrelevante Dinge "übergeben" werden sollen (z.B. die aktuell ausgewählte Seite oder ob ein bestimmtes Menü aus- oder eingeklappt sein soll. Nie jedoch für z.B. einen Login-Status!

Variante 2 hat die gleichen Manipulationsnachteile wie Variante 1. Da Cookies auf dem Client gespeichert werden, ist deren Inhalt beliebig manipulierbar. Dazu kommt, dass bei deaktivierten Cookies die Seite quasi unbenutzbar wird. Der Vorteil ist wie bei Variante 1 die Einfachheit. Zusätzlich bieten Cookies noch die Speicherung von Inhalten über die aktuelle Sitzung hinaus und damit die Möglichkeit den Nutzer z.B. auf die Seite zu leiten, auf der er beim letzten mal aufgehört hat. Nachteilbedingt sind die Einsatzmöglichkeiten die gleichen wie bei Variante 1

Nun zu Variante 3 - der Session. Bei Verwendung einer Session werden die Inhalte direkt auf dem Server gespeichert (entweder in normalen Dateien oder in einer Datenbank). Durch diese räumliche Trennung vom Client sind die Inhalte kaum zu manipulieren.[*]. Die Zuordnung dieser Session-Inhalte geschieht über eine eindeutige Referenz - die Session-ID. Diese ID muß bei jedem Aufruf vom Client geliefert werden. Dafür werden die unter Variante 1 und 2 erläuterten Verfahren benutzt. Die Vorteile liegen auf der Hand. Es wird nur ein einziger Wert direkt zwischen Server und Client per GET-, POST- oder COOKIE-Parameter übermittelt. Dieser kann (und sollte) so "kryptisch" sein, dass sich eine fremde Session-ID praktisch nicht "erraten" läßt. Die Manipulation der Session-Werte von Außen ist damit nahezu unmöglich[*].
Einziger Nachteil ist der etwas komplexere Mechanismus, der aber durch die Session-Verwaltung in PHP so transparent gestaltet ist, dass man faktisch nicht von erhöhtem Aufwand reden kann. Als Nachteil ließe sich vielleicht noch die Mehrbelastung des Servers durch die Datei- bzw. Datenbank-Lese und -Schreibvorgänge anführen.
Sessions sollten also überall dort eingesetzt werden, wo relevante Daten (z.B. ein Login-Status) oder eben sehr viele Scriptübergreifend gespeichert werden müssen.

Anm.[*]: Bevor jetzt alle losschreien was die Manipulation der Werte in einer Session angeht: Ich rede hier von der direkten Manipulierbarkeit! Einen per URL übergeben Wert kann ich direkt ändern - ich muß nur etwas anderes in die Adresszeile des Browsers eintippen. Auch einen Cookie-Wert kann ich direkt ändern, es ist nur etwas komplizierter. Um den Wert einer Session-Variable direkt ändern zu können, muß ich Zugriff auf den jeweiligen Server bzw. die Datenbank bekommen. Dies ist zwar nicht ausgeschlossen (sonst gäbe es kein erfolgreichen Hackerattacken

), aber die Schwelle kann hier entsprechend hoch geschraubt werden.
Was ich hiermit nicht meine ist die INDIREKTE Manipulation von Werten. Wenn das Script einen Session-Wert aufgrund eines URL- oder Cookie-Parameters ändert, dann ist dieser im Endeffekt natürlich genauso leicht zu manipulieren. Die Schwachstelle liegt hier jedoch im Script und nicht im Verfahren selbst.

Gruß Falk

**Arne Drews** · 27.02.2009, 10:50

@Christian:
Ein Formular ist für mich z.B. eine Kontaktaufnahme.
Diese sind i.d.R. (es gibt auch andere Varianten, ich weiß) durch einfache HTML-Tags definiert und werden per POST oder GET übergeben.
Eine Benutzeroberfläche ist für mich dagegen ein, wie man aus Falks Beitrag auch lesen kann, wesentlich datensensitiverer Bereich, für den man sich z.B. mit Benutzername oder Kennwort anmelden muß.
Dort halte ich persönlich Sessions für die beste Lösung!
Daß ich sie dort zwingend brauche, habe ich nie gesagt:

...ist die Wahl der Sessions aber zu empfehlen!

Wer's anders machen möchte, soll das tun...

Announcement

Verständnissproblem Variablen

Verständnissproblem Variablen

Comment

Comment

Comment

Comment

Comment

Comment