Hi,
kann mir jmd. sagen, weshalb es Probleme mit folgendem Konstrukt gibt:
foreach ($_SESSION['kat'] as $kat) {
echo $kat['name'];
}

Wenn ich die Webseite mehrmals aufrufe wird die $_SESSION-Variable
verändert.
Wenn ich $kat in $xyz umbenenne, dann habe ich das Problem nicht.
(dieser Schritt hat mich aber einiges an Zeit gekostet, weshalb ich
wissen will, weshalb das andere falsch ist)

Wäre super, wenn mir jmd. helfen kann.

Gruss,
Christoph

Christoph Hörterer schrieb:
> Hi,
> kann mir jmd. sagen, weshalb es Probleme mit folgendem Konstrukt gibt:
> foreach ($_SESSION['kat'] as $kat) {
> echo $kat['name'];
> }
>
> Wenn ich die Webseite mehrmals aufrufe wird die $_SESSION-Variable
> verändert.
> Wenn ich $kat in $xyz umbenenne, dann habe ich das Problem nicht.
> (dieser Schritt hat mich aber einiges an Zeit gekostet, weshalb ich
> wissen will, weshalb das andere falsch ist)
>
> Wäre super, wenn mir jmd. helfen kann.

Vermutlich hast du register_globals eingeschaltet. Was das ist und was
das für Konsequenzen hat, findest du in der PHP-Referenz deiner Wahl :-)

Daniel

Christoph Hörterer wrote:
> Hi,
> kann mir jmd. sagen, weshalb es Probleme mit folgendem Konstrukt gibt:
> foreach ($_SESSION['kat'] as $kat) {
> echo $kat['name'];
> }
>
> Wenn ich die Webseite mehrmals aufrufe wird die $_SESSION-Variable
> verändert.
> Wenn ich $kat in $xyz umbenenne, dann habe ich das Problem nicht.
> (dieser Schritt hat mich aber einiges an Zeit gekostet, weshalb ich
> wissen will, weshalb das andere falsch ist)

....ich tippe auf register_globals = on in der php.ini! $_SESSION wird in der
Foreach-Schleife mit $_SESSION['kat'] überschrieben, dadurch gehen die
restlichen $_SESSION Variablen übern Jordan.

trage doch mal als erste Zeile deines PHP-Codes folgendes ein:
ini_set('register_globals', '0');

Ändert sich danach das vorher beobachtete Verhalten hin zum gewünschten?

Grüße
Johannes

--
Emails ohne "[nospam]" im Betreff werden kommentarlos gelöscht.

On 31 Aug., 09:19, Christoph Hörterer
<christoph.hoerte... [at] googlemail.com> wrote:
> $_SESSION['kat'] as $kat
Ich gehe mal davon aus, dass du den REGISTER_GLOBALS auf ON stehen
hast.
Dann ist nämlich die =C4nderung an $kat das selbe, als wenn du
$_SESSION['kat'] ändern würdest.
Siehe: http://de.php.net/manual/de/security.globals.php
Grüße, Dirko

Hi,

On 31 Aug., 09:35, "Johannes Mueller" <johanne... [at] gmx.net> wrote:
> Christoph Hörterer wrote:

> > foreach ($_SESSION['kat'] as $kat) {

> ...ich tippe auf register_globals =3D on in der php.ini! $_SESSION wird i=
n der
> Foreach-Schleife mit $_SESSION['kat'] überschrieben, dadurch gehen die
> restlichen $_SESSION Variablen übern Jordan.

Ja, war eingeschaltet. Danke.

> trage doch mal als erste Zeile deines PHP-Codes folgendes ein:
> ini_set('register_globals', '0');

Hat leider nichts geholfen. Aber die =C4nderung an der php.ini hat
funktioniert.

> =C4ndert sich danach das vorher beobachtete Verhalten hin zum gewünscht=
en?

Ja. Mir war die Tragweite von register_globals nicht bewusst. Gut,
dass meine Anwendung in einem geschlossenen Bereich (Server2Go)
abläuft und nicht übers Internet erreichbar ist...

> Grüße
> Johannes

Gruss,
Christoph

Johannes Mueller wrote:

Hallo,

> ...ich tippe auf register_globals =3D on in der php.ini! $_SESSION wi=
rd in
> der Foreach-Schleife mit $_SESSION['kat'] überschrieben, dadurch ge=
hen die
> restlichen $_SESSION Variablen übern Jordan.
>
> trage doch mal als erste Zeile deines PHP-Codes folgendes ein:
> ini_set('register_globals', '0');

Was sich auch verhindern lässt, in dem innerhalb von $_SESSION
ein Präfix benutzt wird, dass ansonsten nicht für Variablennamen
benutzt wird.

$_SESSION['sesKat'];

Eine andere Nebenwirkung gibt es dadurch, dass sich alle Programme
in der Regel ein Verzeichnis zum Speichern der Sessiondaten
teilen. Wenn nun verschiedene Programme gleiche Namen benutzen kommt
es wiederum zu einer Kollision. Das lässt sich mit Präfixes einsch=
ränken
und setzen eines session.save_path oder session.save_handler pro Skrip=
t
zur Laufzeit ganz verhindern.


tschuess
[|8:)

Sven Drieling schrieb:
> Johannes Mueller wrote:
>
> Hallo,
>
>> ...ich tippe auf register_globals = on in der php.ini! $_SESSION wird in
>> der Foreach-Schleife mit $_SESSION['kat'] überschrieben, dadurch gehen die
>> restlichen $_SESSION Variablen übern Jordan.
>>
>> trage doch mal als erste Zeile deines PHP-Codes folgendes ein:
>> ini_set('register_globals', '0');
>
> Was sich auch verhindern lässt, in dem innerhalb von $_SESSION
> ein Präfix benutzt wird, dass ansonsten nicht für Variablennamen
> benutzt wird.
>
> $_SESSION['sesKat'];

register_globals auszuschalten ist hier aber die bessere Lösung (wenn es
geht).

>
> Eine andere Nebenwirkung gibt es dadurch, dass sich alle Programme
> in der Regel ein Verzeichnis zum Speichern der Sessiondaten
> teilen. Wenn nun verschiedene Programme gleiche Namen benutzen kommt
> es wiederum zu einer Kollision. Das lässt sich mit Präfixes einschränken
> und setzen eines session.save_path oder session.save_handler pro Skript
> zur Laufzeit ganz verhindern.

Nanu, was für einen komischen save_handler hast du denn? Also meiner
speichert alles in Dateien, deren Namen im Wesentlichen aus der
Session-ID bestehen. Und die ist nun mal per Definition eindeutig.

Da brauche ich mich um (fast) nichts mehr zu kümmern.

Oder von welchen "Programmen" redest du?

Daniel

Johannes Mueller wrote:

> trage doch mal als erste Zeile deines PHP-Codes folgendes ein:
> ini_set('register_globals', '0');

Haste das wenigstens mal probiert Johannes?

Das was Du da tun willst geht natürlich nicht. An der Stelle wo dieser
Code ausgeführt wird liegen die Daten längst so vor wie nicht erwünscht.

Entweder per .htaccess oder in der php.ini setzen. Anders gehts nicht.

MfG, Ulf

--
_,
_(_p> Ulf [Kado] Kadner
\<_)
^^

Ulf Kadner wrote:
> Johannes Mueller wrote:
>
>> trage doch mal als erste Zeile deines PHP-Codes folgendes ein:
>> ini_set('register_globals', '0');
>
> Haste das wenigstens mal probiert Johannes?
>
> Das was Du da tun willst geht natürlich nicht. An der Stelle wo dieser
> Code ausgeführt wird liegen die Daten längst so vor wie nicht
> erwünscht.
> Entweder per .htaccess oder in der php.ini setzen. Anders gehts nicht.

*grmpf*

Grüße
Johannes

PS: gib zu, es ist die Retourkutsche für
<news:5htuc7F3hi9qdU1 [at] mid.uni-berlin.de> ;p

--
Emails ohne "[nospam]" im Betreff werden kommentarlos gelöscht.

Sven Drieling schrieb:

> Eine andere Nebenwirkung gibt es dadurch, dass sich alle Programme
> in der Regel ein Verzeichnis zum Speichern der Sessiondaten
> teilen. Wenn nun verschiedene Programme gleiche Namen benutzen kommt
> es wiederum zu einer Kollision.

Was für eine Kollision? Was soll da kollidieren?

Wenn mehrere Scripte dieselbe Session-ID benutzen, gehören sie zur
selben Session und schreiben ihre Daten jeweils in dieselbe
Session-Datei. Das soll so sein und ist auch so gewollt.

Oder meinst Du etwas Anderes?

Gruß. Claus

Daniel Fett wrote:

Hallo,

>> Eine andere Nebenwirkung gibt es dadurch, dass sich alle Programme
>> in der Regel ein Verzeichnis zum Speichern der Sessiondaten
>> teilen. Wenn nun verschiedene Programme gleiche Namen benutzen komm=
t
>> es wiederum zu einer Kollision. Das lässt sich mit Präfixes ein=
schränken
>> und setzen eines session.save_path oder session.save_handler pro Sk=
ript
>> zur Laufzeit ganz verhindern.
>
> Nanu, was für einen komischen save_handler hast du denn? Also meine=
r
> speichert alles in Dateien, deren Namen im Wesentlichen aus der
> Session-ID bestehen. Und die ist nun mal per Definition eindeutig.

Ja, und das in der Regel (session.cookie_path =3D "/") für alle *.ph=
p,
die auf dem Server laufen egal, ob eigene oder fremde. Wenn eins diese=
r
*.php eine $_SESSION['Kat'] setzt, dann steht $_SESSION['Kat'] auch
in allen anderen *.php zur Verfügung, was ja der Sinn von Sessions
ist. Nur wenn die *.php zu verschiedenen Programmen(, von verschiedene=
n
Autoren) gehören kann es so zu Namenskollisionen innerhalb von
$_SESSION kommem.

session.name ist weitere Möglichkeiten, um eine solche Kollision zu
verhindern.


tschuess
[|8:)

Johannes Mueller wrote:

> PS: gib zu, es ist die Retourkutsche für
> <news:5htuc7F3hi9qdU1 [at] mid.uni-berlin.de> ;p

hehe :-) Hatte ich eigentlich schon längst wieder vergessen. Aber wenn
Du es so ansprichst. ;-)

MfG, Ulf


--
_,
_(_p> Ulf [Kado] Kadner
\<_)
^^

..oO(Sven Drieling)

>Daniel Fett wrote:
>
>> Nanu, was für einen komischen save_handler hast du denn? Also meiner
>> speichert alles in Dateien, deren Namen im Wesentlichen aus der
>> Session-ID bestehen. Und die ist nun mal per Definition eindeutig.
>
> Ja, und das in der Regel (session.cookie_path = "/") für alle *.php,
> die auf dem Server laufen egal, ob eigene oder fremde. Wenn eins dieser
> *.php eine $_SESSION['Kat'] setzt, dann steht $_SESSION['Kat'] auch
> in allen anderen *.php zur Verfügung, was ja der Sinn von Sessions
> ist. Nur wenn die *.php zu verschiedenen Programmen(, von verschiedenen
> Autoren) gehören kann es so zu Namenskollisionen innerhalb von
> $_SESSION kommem.

Verwexelst Du da was? Was andere Autoren (im Sinne von Sitebetreiber)
machen, interessiert überhaupt nicht, selbst wenn deren Session-Dateien
alle im selben Ordner liegen sollten.

Kannst Du ein konkretes Beispiel geben, wie Du Dir eine solche Kollision
vorstellst?

Micha

Michael Fesser wrote:

Hallo,

>> Ja, und das in der Regel (session.cookie_path =3D "/") für alle *.=
php,
>> die auf dem Server laufen egal, ob eigene oder fremde. Wenn eins die=
ser
>> *.php eine $_SESSION['Kat'] setzt, dann steht $_SESSION['Kat'] auch
>> in allen anderen *.php zur Verfügung, was ja der Sinn von Sessions=

>> ist. Nur wenn die *.php zu verschiedenen Programmen(, von verschiede=
nen
>> Autoren) gehören kann es so zu Namenskollisionen innerhalb von
>> $_SESSION kommem.
>
> Verwexelst Du da was? Was andere Autoren (im Sinne von Sitebetreiber)=


Autor im Sinne von Programmierer (schreiben von Programmen).

Zwei unterschiedliche Programme von verschiedenen Programmierern auf
einer Website.

SvensForumSkript.php

<?php
session_start();

$_SESSION['login'] =3D true;
?>


IndysBlogSkript.php

<?php
session_start();

if(true =3D=3D=3D $_SESSION['login']) {
}
?>

Automatisch eingeloggt, obwohl der Login für SvensForumSkript.php
erfolgte.


Besser z.B.

IndysBlogSkript.php

<?php
session_start();

if(true =3D=3D=3D $_SESSION['idyblg']['login']) {
}
?>



tschuess
[|8:) http://www.sven-drieling.de/

..oO(Sven Drieling)

>Michael Fesser wrote:
>
>Hallo,
>
>>> Ja, und das in der Regel (session.cookie_path = "/") für alle *.php,
>>> die auf dem Server laufen egal, ob eigene oder fremde. Wenn eins dieser
>>> *.php eine $_SESSION['Kat'] setzt, dann steht $_SESSION['Kat'] auch
>>> in allen anderen *.php zur Verfügung, was ja der Sinn von Sessions
>>> ist. Nur wenn die *.php zu verschiedenen Programmen(, von verschiedenen
>>> Autoren) gehören kann es so zu Namenskollisionen innerhalb von
>>> $_SESSION kommem.
>>
>> Verwexelst Du da was? Was andere Autoren (im Sinne von Sitebetreiber)
>
> Autor im Sinne von Programmierer (schreiben von Programmen).
>
> Zwei unterschiedliche Programme von verschiedenen Programmierern auf
> einer Website.

Ah! Das ist also der Punkt - auf _einer_ Website, ergo unter derselben
Domain. Völlig logisch, daß das zu Problemen führen kann. Allerdings
sind diese Probleme nicht nur auf Sessions beschränkt, genausogut
könnten sie sich (theoretisch) gegenseitig die Datenbank schrotten.

Micha

Sven Drieling schrieb:

> Zwei unterschiedliche Programme von verschiedenen Programmierern auf
> einer Website.
>
> SvensForumSkript.php
>
> <?php
> session_start();
>
> $_SESSION['login'] = true;
> ?>
>
>
> IndysBlogSkript.php
>
> <?php
> session_start();
>
> if(true === $_SESSION['login']) {
> }
> ?>
>
> Automatisch eingeloggt, obwohl der Login für SvensForumSkript.php
> erfolgte.

Wenn IndysBlogSkript.php in der gleichen Session aufgerufen wird wie
SvensForumSkript.php, dann ist das so und soll auch so sein. Das ist der
Sinn einer Session.

Gruß. Claus

HI Michael

Michael Fesser wrote:
> .oO(Sven Drieling)
>> Michael Fesser wrote:
>>>> Ja, und das in der Regel (session.cookie_path = "/") für alle *.php,
>>>> die auf dem Server laufen egal, ob eigene oder fremde. Wenn eins dieser
>>>> *.php eine $_SESSION['Kat'] setzt, dann steht $_SESSION['Kat'] auch
>>>> in allen anderen *.php zur Verfügung, was ja der Sinn von Sessions
>>>> ist. Nur wenn die *.php zu verschiedenen Programmen(, von verschiedenen
>>>> Autoren) gehören kann es so zu Namenskollisionen innerhalb von
>>>> $_SESSION kommem.
>>> Verwexelst Du da was? Was andere Autoren (im Sinne von Sitebetreiber)
>> Autor im Sinne von Programmierer (schreiben von Programmen).
>> Zwei unterschiedliche Programme von verschiedenen Programmierern auf
>> einer Website.
> Ah! Das ist also der Punkt - auf _einer_ Website, ergo unter derselben
> Domain. Völlig logisch, daß das zu Problemen führen kann. Allerdings
> sind diese Probleme nicht nur auf Sessions beschränkt, genausogut
> könnten sie sich (theoretisch) gegenseitig die Datenbank schrotten.

Wieso sollen sie? So lange jeder seine eigene DB betreibt ist es also
wurscht und zusammenhangslos zu obigem.

HTH, Johannes

Hi Claus

Claus Reibenstein wrote:
> Wenn IndysBlogSkript.php in der gleichen Session aufgerufen wird wie
> SvensForumSkript.php, dann ist das so und soll auch so sein. Das ist der
> Sinn einer Session.

Besseres Beispiel zur Verdeutlichung: Ein Konzern, der zwar alle Seiten
unter www.concern.com/ betreibt, jedoch seinen Abteilungen jeweils freie
Hand lässt bei der Gestaltung ihrer Subseiten. Da die Session über
Cookie abgespeichert und dieses auf path=/ gemünzt ist, kann schnell mal
eine Verwechslung stattfinden.

HTH zur Klärung.
Johannes