PHP unterschiede in der Laufzeitumgebung?!?

[Haymaker84]

Hallo,

ich habe in PHP einen kleinen Online-Shop programmiert.

Den habe ich lokal mit XAMPP entwickelt. Da hat alles ohne Probleme funktioniert.

Dann hab ich das ganze bei Web.de auf den Webspace gepackt und schon treten total merkwürdige Unterschiede auf:

Wenn ich bei der ersten Aktion von Artikel A 5 Stück in der Warekorb packe, funktioniert das Wenn ich im 2. Schritt von Artikel B einen in den Warenkorb lege, steht plötzlich, dass von Artikel A 2 Stück im Cart sind. Artikel B wird nicht erwähnt...

Gibt es da Unterschiede im Session-Tracking oder eingeschränkte zugriffe? :eek

Ich kann das ganze ja schlecht debuggen

[flashpixx]

Hallo,

schau Dir doch mal die Serverlogs an, da sollten die Fehler angezeigt werden

Phil

[Haymaker84]

Hi nochmal...

ich hab bis eben gekäpft und jetzt funktionierts. :cool:

ich musste alle normalen "variablen" rausnehmen z.B. $var und durch Session Variablen ersetzen $_SESSION['var']...

:upps

das funktioniert ohne Probleme. Mir völlig unerklärlich...

Wie kann sowas sein?!?!

[Haymaker84]

Hallo,

schau Dir doch mal die Serverlogs an, da sollten die Fehler angezeigt werden

Phil

ich hab mit

error_reporting(E_ALL);

ini_set('display_errors', TRUE);

gearbeitet. das gab immer nur "Notice: Undefined index: xxx" an, wenn eine Session - variable noch nicht gesetzt wurde.

[Aiun]

ich musste alle normalen "variablen" rausnehmen z.B. $var und durch Session Variablen ersetzen $_SESSION['var']...

ich hoffe nicht "alle" ?

ich würde eigentlich von sessionvariablen abraten, dann schreib eher dein eigenes Session-Handling mit oder ohne cookies, was php mit den Sessions anstellt, ist oft abhängig davon wie der Server eingestellt.

häufigster Fehler ist der unterschied zwischen Windows und Unix-Umgebungen bzgl. groß / Kleinschreibung.

[Toothrot]

Wie kann sowas sein?!?!

XAMPP ist standardmäßig ziemlich unsicher konfiguriert.

PHP: Verwendung von Register Globals - Manual

[Haymaker84]

ich hoffe nicht "alle" ?

ich würde eigentlich von sessionvariablen abraten, dann schreib eher dein eigenes Session-Handling mit oder ohne cookies, was php mit den Sessions anstellt, ist oft abhängig davon wie der Server eingestellt.

Komischerweise nicht alle nicht alle, denn auf ...

PHP: Verwendung von Register Globals - Manual

... habe ich folgende Aussage gefunden:

(vielen Dank übrigens für den Link - sehr Aufschlussreich)

$_SESSION['value'] = 'some value';

$value = 'another value';

echo $_SESSION['value']; // !!! will print 'another value' !!!!

Hope this will save someone from headaches and from loosing hours!

Das müsste mit meinem Problem zusammenhängen (nur die Verarbeitung von Session-Variablen macht Probleme). Ich kapier nur nicht, wie das zustande kommt?!

Aber prinzipiell denke ich nicht, dass es gut wäre das Rad neu zu erfinden.

So schlecht können php sessions doch nicht sein, als das man mal eben schnell was besseres implementieren könnte?!

[geloescht_JesterDay]

... habe ich folgende Aussage gefunden:

(vielen Dank übrigens für den Link - sehr Aufschlussreich)

$_SESSION['value'] = 'some value';

$value = 'another value';

echo $_SESSION['value']; // !!! will print 'another value' !!!!

Hope this will save someone from headaches and from loosing hours!

Das müsste mit meinem Problem zusammenhängen (nur die Verarbeitung von Session-Variablen macht Probleme). Ich kapier nur nicht, wie das zustande kommt?!

Das sollte aber nur gehen, wenn register_globals on ist. Auch auf dem Link, ganz oben und fett:

This feature is DEPRECATED and REMOVED as of PHP 6.0.0. Relying on this feature is highly discouraged.

Du solltest das also auf keinen Fall verwenden und wann immer möglich abschalten!

Das kannst du auch in der .htaccess Datei tun, wenn du keinen Zugriff auf die php.ini hast:

#.htaccess


php_flag register_globals off 

Dann klappts auch mit dem Nachbarn

Ich versteh auch nciht, wie Aiun sein eigenes Session Handling implementieren will ohne Cookies. Ok, es gibt ja die Möglichkeit das über die URL zu machen, aber das ist IMHO auch nicht besonders toll, da du damitdie SessionID Bookmarken oder weitergeben kannst (ungewollt). Das kann man alles auch abfangen indem man die Session nach einer gewissen Zeit oder auf Kommando löscht und die alte ID dann nutzlos ist, aber bringt der aufwand wirklich was?

Und eine Session über die IP-Adresse ist auch keine Lösung, IMHO. In Zeiten von dynamischen IPs ist das IMHO eine sehr große Sicherheitslücke (Damit meine ich nicht, SessionID an eine IP binden, sondern die Session nur über die IP bestimmen).

Das was dir hier passiert ist eigentlich der Grund, warum ich niemandem XAMPP empfehlen würde, wenn der nicht wirklich genau weiß was er tut und Ahnung von der Sache hat. Weil XAMPP wirklich eine Sch*$ß Config hat und du das eben dann nicht 1:1 einfach auf einen Server im Web kopieren kannst.

[Aiun]

nur zur Verteidigung ^^ Cookies sind die beste Lösung für Sessions, mir ging es nur darum sich nicht auf das PHP-Sessionhandling zu verlassen, ob so oder so, sessions lieber selbst verwalten.

[geloescht_JesterDay]

...mir ging es nur darum sich nicht auf das PHP-Sessionhandling zu verlassen,...

Naja, oder man legt seiner Anwendung eine .htaccess bei, in der alle Einstellungen entsprechend gesetzt werden, wie man es braucht

Ich denke halt, wenn PHP schon ein Sessionhandling anbietet, dann sollte man das auch nutzen, denn was eigenes wird auf jeden Fall nicht schneller und besser sein. Und so wirklich anders könntest du das IMHO ja auch nicht lösen.

die SessionID wird ja eh vergeben und dann auch von dir genutzt. Und dann? Willst du die Daten selbst in eine Datei schreiben? Macht PHP doch standardmäßig auch. Oder in eine DB? Kann man auch einstellen, dass Sessions nicht über Textdateien sondern mit z.B. MySQL gehandelt werden.

Wenn man kein register_globals verwendet (was ja ab php 6.0.0 eh raus ist), sollte es damit keinerlei Probleme geben. Zumindest kann ich mir nicht vorstellen welche.