variablen_definition

[carsten schlichting]

Hallo

ist es eigentlich zu empfehlen in den programmschleifen direkt mit $_SESSION['...'] áls variable zu arbeiten ( oder z.B. mit $_GET['...'], oder sollte man anders den wert in eine interne Variable umschreiben?

Viele Grüße von mir

carsten

[carsten schlichting]

sorry das mit der Themen_Überschrift ist aus Versehen falsch gelaufen.

carsten

[Marc Reichelt]

Hallo carsten,

ist es eigentlich zu empfehlen in den programmschleifen direkt mit $_SESSION['...'] áls variable zu arbeiten ( oder z.B. mit $_GET['...'], oder sollte man anders den wert in eine interne Variable umschreiben?

Das ist, sobald man die Variablen öfters braucht, etwas umkomfortabel.
Machen kannst du es, niemand verbietet es dir - und es kommt ganz auf den Anwendungsfall drauf an.
Bei $_SESSION gibt es aber z.B. folgendes zu beachten:

$_SESSION['name'] = 'wert';

und

$name = $_SESSION['name'];  
$name = 'wert';

sind nicht gleich!
Im ersten Fall wird der Wert in der Session geändert, im zweiten Fall nicht.

Bei $_GET und $_POST lohnt es sich aber meistens doch, "interne Variablen" anzulegen - natürlich erst nach einer Prüfung der Existenz und des Inhalts.

Grüße

Marc Reichelt || http://www.marcreichelt.de/

[carsten schlichting]

Hi danke

Prüfung des Inhaltes ist ja einmal dafür da, das das Prpgramm überhaupt funktioniert oder?

habe aber auch schon mal gelesen, das der Inhalt auf schrägstriche und so geprüft wird, um Hackerangriffe zu unterbinden, die über die url eingegeben werden.

stimmt das?

[Rouven]

Hi,

na ja, die Antwort ist: Die Prüfung ist sowohl für die reine Funktion als auch für die Sicherheit da. Deine Software muss natürlich prüfen, ob die Informationen die übermittelt wurden im Kontext der Anwendung Sinn machen. Die eMail-Adresse "123" wäre demnach eher hinderlich.
Aber gleichzeitig könnten Hacker jegliche Art von Schwachstelle im Code ausnutzen um Informationen oder Rechte zu erlangen. Ein Paradebeispiel ist das Austricksen eines Login-Skriptes:
Variablen $user und $password
--> Abfrage
SELECT * FROM users WHERE user = '$user' AND password = '$password'
Soweit so gut, PHP bringt auch ein paar Sicherheitsmechanismen mit, damit dies nicht passiert, aber nur mal hypothetisch: Was wäre, wenn jemand als $password
  xyz' OR 'abc'='abc
angibt? In das Statement eingesetzt gibt das eine Abfrage, die den User erfolgreich anmeldet (sofern er existiert, sonst macht man das selbe mit dem Benutzernamen nochmal.

Daher: Inhalte immer prüfen.

MfG
Rouven

[dedlfix]

echo $begrüßung;

habe aber auch schon mal gelesen, das der Inhalt auf schrägstriche und so geprüft wird, um Hackerangriffe zu unterbinden, die über die url eingegeben werden.

Das was du gelesen hast wird sicher irgendetwas mit dem Magic-Quotes-Mechanismus zu tun haben. Der soll durch das automatische Einfügen von \ vor ',",\ und NULL-Zeichen in GET/POST/COOKIE-Daten einen gewissen Schutz vor SQL-Injection bieten.
Wenn man nun aber gar keine Datenbank mit den Eingabewerten füttern möchte hat man überflüssige Backslashes in seinen Daten. Und außerdem gibt noch ein paar mehr Zeichen, die maskiert werden müssen, und die beachtet dieser Mechanismus nicht.
Mit anderen Worten: Magic-Quotes sind gut gemeint und "gut gemeint" ist oft das Gegenteil von "gut".

Also: Magic-Quotes ausschalten, oder zum Scriptbeginn entfernen, wenn man keinen Konfigurationszugriff hat. Und für das jeweilige Ausgabemedium die passenden Funktionen zum Maskieren verwenden.

echo "$verabschiedung $name";

[Tom]

Hello,

Bei $_GET und $_POST lohnt es sich aber meistens doch, "interne Variablen" anzulegen - natürlich erst nach einer Prüfung der Existenz und des Inhalts.

Die Arrays sind alle ganz normale "interne Variablen". Während der Laufzeit des Scriptes stehen sie nur diesem zur Verfügung. Warum also noch weitere redundante Daten erzeugen? Schließlich haben wir in der PHP 4.3.8 noch immer die redundanten globalen (nicht superglöbalen) Arrays der alten Generation. Die würde ich z.B. gleich zu Anfang des Scriptes löschen, damit der Speicher zurückgegeben werden kann.

Harzliche Grüße vom Berg
esst mehr http://www.harte-harzer.de

Tom

[Marc Reichelt]

Hallo Tom,

Bei $_GET und $_POST lohnt es sich aber meistens doch, "interne Variablen" anzulegen - natürlich erst nach einer Prüfung der Existenz und des Inhalts.

Die Arrays sind alle ganz normale "interne Variablen". Während der Laufzeit des Scriptes stehen sie nur diesem zur Verfügung. Warum also noch weitere redundante Daten erzeugen?

Das bleibt - wie übrigens schon gesagt - jedem selbst überlassen. Bei mir selbst hat sich es als guter Stil erwiesen, die Inhalte von $_GET und $_POST als gefährlich zu betrachten und erst nach eingehender Prüfung die entsprechenden Variablen anzulegen.
Aus dieser einfachen Trennung folgt IMHO Übersichtlichkeit und dementsprechend auch Sicherheit, da man den Überblick nicht so schnell verliert.

Grüße

Marc Reichelt || http://www.marcreichelt.de/

[Eternius]

Hallo,

das kommt darauf an, ob du z.B. planst die skripte auch irgendwann consolentauglich zu machen.

gruss

[carsten schlichting]

Hi

was meinst du mit Konsolentauglich?

gruß zurück
carsten

[Eternius]

Hallo,

wenn du planst diese skripte auch von der console ausführen zu können, oder
code aus den skripten weiterzuverwenden, und dort zu verwenden wo das session, bzw get, post konzept nicht existiert.

gruss

[carsten schlichting]

nö das brauch ich nicht.

hab auch vor mit php scripten was internes jenseits des Server zu machen,

aber das werd ich mit einem Testserver (XAMPP)und den Browsern machen.

so denk ich

[dedlfix]

echo $begrüßung;

ist es eigentlich zu empfehlen in den programmschleifen direkt mit $_SESSION['...'] áls variable zu arbeiten ( oder z.B. mit $_GET['...'], oder sollte man anders den wert in eine interne Variable umschreiben?

Gemäß eines Userkommentares im PHP-Handbuch-Kapitel zu Sessions, findet für jedes $_SESSION['...'] ein Dateizugriff statt. Wenn du also Performance-Probleme (wegen vieler Zugriffe auf $_SESSION und/oder einem langsamen session.save_path) hast, solltest du über das Arbeiten mit internen Variablen/Array nachdenken. Ansonsten könnte der Umkopiervorgang mehr kosten als er Nutzen bringt.

echo "$verabschiedung $name";

[Tom]

Hello,

Gemäß eines Userkommentares im PHP-Handbuch-Kapitel zu Sessions, findet für jedes $_SESSION['...'] ein Dateizugriff statt. Wenn du also Performance-Probleme (wegen vieler Zugriffe auf $_SESSION und/oder einem langsamen session.save_path) hast, solltest du über das Arbeiten mit internen Variablen/Array nachdenken. Ansonsten könnte der Umkopiervorgang mehr kosten als er Nutzen bringt.

meintest Du etwa:

Standard Array: 0.102ms
  $_SESSION: 0.197

Das ist überhaupt keine wertige Aussage.
Wenn es sich um eine Verhundertfachung der Zeit handeln würde, würde ich mal nachforschen.
Hier hilft wohl nur ein Blick in den Quellcode.

Aber schon alleine vom Handling wäre das Unsinn.
Sessionvariablen werden definitiv erst im Exit-Handler des Scriptes zurückgeschrieben in die Sessiondatei. Sie werden mit Session_Start() einmalig gelesen. Nachfolgende Veränderungen (z.B. durch ein weiteres Script) der Sessiondatei haben keinen Einfluss auf die Variableninhalte und ihre Werte innerhalb des ersten Scriptes.

Interessant wäre jetzt aber tatsächlich das dynamische Verhalten der Session, ob das in PHP schon vorgesenen ist. Aber vermutlich (ich werde das nochmal untersuchen) wird die Sessiondatei genaus platt gelesen und geschrieben, wie jedes andere Flatfile. Das hieße dann also, dass der letzte Schreiber Recht behält und man sich selber um die Konsistenz der Session kümmern muss.

Harzliche Grüße vom Berg
esst mehr http://www.harte-harzer.de

Tom

[dedlfix]

echo $begrüßung;

meintest Du etwa:

Standard Array: 0.102ms
  $_SESSION: 0.197

Wie du sicherlich weißt, lege ich keinen Wert auf unsinniges Herauskitzeln jedes noch so kleinen Fitzelchens Laufzeit, deswegen schränkte ich meine Empfehlung auch mit den Worten ein: "Wenn du also Performance-Probleme ... hast". Es besteht also kein Grund zur Panik oder in Aktionismus zu verfallen, wenn man keine solchen Probleme hat.

Sessionvariablen werden definitiv erst im Exit-Handler des Scriptes zurückgeschrieben in die Sessiondatei. Sie werden mit Session_Start() einmalig gelesen.

Das mag sein (bezogen auf den zweiten Satz, den ersten zweifele ich nicht an).

Nachfolgende Veränderungen (z.B. durch ein weiteres Script) der Sessiondatei haben keinen Einfluss auf die Variableninhalte und ihre Werte innerhalb des ersten Scriptes.

Das findet sowieso nicht statt, da gemäß Handbuchseite zu session_write_close() (auch auf deutsch) die Sessiondatei gesperrt ist, wenn ein Script sie grad "in der Mache hat".

[...] Das hieße dann also, dass der letzte Schreiber Recht behält und man sich selber um die Konsistenz der Session kümmern muss.

Nicht wenn man dem Handbuch Glauben schenken darf.

echo "$verabschiedung $name";

[Tom]

Hello,

Nachfolgende Veränderungen (z.B. durch ein weiteres Script) der Sessiondatei haben keinen Einfluss auf die Variableninhalte und ihre Werte innerhalb des ersten Scriptes.

Das findet sowieso nicht statt, da gemäß Handbuchseite zu session_write_close() (auch auf deutsch) die Sessiondatei gesperrt ist, wenn ein Script sie grad "in der Mache hat".

Ich glaube bei PHP nichts, solange ich es nicht selbst ausprobiert habe.
Aber hier hast Du Recht. Solange ein Script mit einer Sessiondatei arbeitet, ist diese exclusiv gesperrt.

Testszenario:
Sessiondatei erzeugen.

Srcipt 1
  session-id auf die erzeugte setzen
  Script starten.
  es läuft solange, bis man eine Kontrolldatei weglöscht

Script 2
  session-id auf die erzeugte setzen
  Script starten.
  es wartet solange, bis es auf die Sessiondatei zugreifen kann.
  Nach Stoppen von Script 1 kommt die geforderte Ausgabemeldung "Session xyz gestaret"

Drum prüfe, wer sich an PHP bindet ;-))

Harzliche Grüße vom Berg
esst mehr http://www.harte-harzer.de

Tom