Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.comp.lang.php > #3952 > unrolled thread

Die Tuecken von session_status()

Back to article view | Back to de.comp.lang.php

Contents

  Die Tuecken von session_status() Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2016-09-08 10:16 +0000
    Re: Die Tuecken von session_status() k@rl.pflaesterer.de (Karl Pflästerer) - 2016-09-08 14:21 +0200
      Re: Die Tuecken von session_status() Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2016-09-08 22:14 +0000
        Re: Die Tuecken von session_status() k@rl.pflaesterer.de (Karl Pflästerer) - 2016-09-09 08:56 +0200
          Re: Die Tuecken von session_status() Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2016-09-09 09:09 +0000
            Re: Die Tuecken von session_status() k@rl.pflaesterer.de (Karl Pflästerer) - 2016-09-09 14:25 +0200
              Re: Die Tuecken von session_status() Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2016-09-09 17:03 +0000
                Re: Die Tuecken von session_status() k@rl.pflaesterer.de (Karl Pflästerer) - 2016-09-09 20:46 +0200
                  Re: Die Tuecken von session_status() Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2016-09-11 16:06 +0000
        Re: Die Tuecken von session_status() "Christoph M. Becker" <cmbecker69@arcor.de> - 2016-09-09 19:39 +0200
          Re: Die Tuecken von session_status() Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2016-09-11 16:02 +0000
            Re: Die Tuecken von session_status() "Christoph M. Becker" <cmbecker69@arcor.de> - 2016-09-15 15:25 +0200
              Re: Die Tuecken von session_status() Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2016-10-02 18:48 +0000
                Re: Die Tuecken von session_status() "Christoph M. Becker" <cmbecker69@arcor.de> - 2016-10-03 19:47 +0200

#3952 — Die Tuecken von session_status()

session_status() gibt an, ob eine Session existiert oder nicht.

Aber kann ich irgendwie herausbekommen, ob ich mich gerade *im*
Aufbau einer Session befinde, d.h. im Initialisierungscode von darin
enthaltenen Objekten?

Servus,
   Stefan

-- 
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Laune mit Stefan, gelassen und blau!
(Sloganizer)

[toc] | [next] | [standalone]

#3953

Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) writes:

> session_status() gibt an, ob eine Session existiert oder nicht.
>
> Aber kann ich irgendwie herausbekommen, ob ich mich gerade *im*
> Aufbau einer Session befinde, d.h. im Initialisierungscode von darin
> enthaltenen Objekten?

Was ist, wenn du
http://php.net/manual/en/function.session-set-save-handler.php nutzt und
einen eigenen Sessionhandler definierst?

KP

[toc] | [prev] | [next] | [standalone]

#3954

On Thu, 08 Sep 2016 14:21:28 Karl Pflästerer wrote:
> Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) writes:
> > [...] kann ich irgendwie herausbekommen, ob ich mich gerade *im*
> > Aufbau einer Session befinde, d.h. im Initialisierungscode von darin
> > enthaltenen Objekten?

> Was ist, wenn du
> http://php.net/manual/en/function.session-set-save-handler.php nutzt und
> einen eigenen Sessionhandler definierst?

Ich hatte gehofft, mir nicht die Hände schmutzig machen zu müssen.

Und mir ist auch unklar, wie der Sessionhandler auszusehen hätte.

SessionHandler::read() wird aufgerufen, um die serialisierten Daten
zu lesen. Dummerweise scheint die Initialisierung der geladenen
Daten erst danach zu erfolgen, und ausserhalb der via Interface
zugänglichen Methoden :-/

Ein spontaner Versuch:

#v+
class SessionHandler_MyKassa extends SessionHandler {

        public static $initializing = false;

        public function read($session_id) {
		echo "ANFANG";
                $this->initializing = true;
                $result = parent::read($session_id);
                $this->initializing = false;
		echo "ENDE";
                return $result;
        }

        public static function isInitializing() : Bool {
                return self::$initializing;
        }
}
#v-

...hat jedenfalls gezeigt, dass "ENDE" erreicht wird, bevor das
erste __wakeup aufgerufen wird. Blöd.

Servus,
   Stefan

-- 
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Zerspülte Hemmungen! Stefan, immer Freitags und zwischendurch!
(Sloganizer)

[toc] | [prev] | [next] | [standalone]

#3955

Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) writes:

> On Thu, 08 Sep 2016 14:21:28 Karl Pflästerer wrote:
>> Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) writes:
>> > [...] kann ich irgendwie herausbekommen, ob ich mich gerade *im*
>> > Aufbau einer Session befinde, d.h. im Initialisierungscode von darin
>> > enthaltenen Objekten?
>
>> Was ist, wenn du
>> http://php.net/manual/en/function.session-set-save-handler.php nutzt und
>> einen eigenen Sessionhandler definierst?
>
> Ich hatte gehofft, mir nicht die Hände schmutzig machen zu müssen.
>
> Und mir ist auch unklar, wie der Sessionhandler auszusehen hätte.
>
> SessionHandler::read() wird aufgerufen, um die serialisierten Daten
> zu lesen. Dummerweise scheint die Initialisierung der geladenen
> Daten erst danach zu erfolgen, und ausserhalb der via Interface
> zugänglichen Methoden :-/
>
> Ein spontaner Versuch:
>
>
> #v+
> class SessionHandler_MyKassa extends SessionHandler {
>
>         public static $initializing = false;
>
>         public function read($session_id) {
> 		echo "ANFANG";
>                 $this->initializing = true;
>                 $result = parent::read($session_id);
>                 $this->initializing = false;
> 		echo "ENDE";
>                 return $result;
>         }
>
>         public static function isInitializing() : Bool {
>                 return self::$initializing;
>         }
> }
> #v-
>
>
> ...hat jedenfalls gezeigt, dass "ENDE" erreicht wird, bevor das
> erste __wakeup aufgerufen wird. Blöd.

Kannst du das Problem genauer schildern, dass du lösen möchtest? Die
betreffenden Objekte werden also nicht nur in Sessiondaten gespeichert
und aus diesen deserialisiert? Man könnte eventuuell das Problem auch
umgekehrt angehen und sagen, man geht davon aus, dass man *in* einer
Session ist, es sei denn man legt im Code fest, dass dies nicht so ist.
Letzeres ist vielleicht in deinem Fall leicher umzusetzen.

  KP

[toc] | [prev] | [next] | [standalone]

#3956

On Fri, 09 Sep 2016 08:56:05 Karl Pflästerer wrote:
> Kannst du das Problem genauer schildern, dass du lösen möchtest?

Dann will mir ganz bestimmt wieder jemand ausreden, das zu tun, was
ich mache :-)

> Die betreffenden Objekte werden also nicht nur in Sessiondaten
> gespeichert und aus diesen deserialisiert?

Ich hänge mich gerade bei einer Reihe von Singletons in den
Initialisierungscode, um dort eine Berechtigungsprüfung
durchzuführen; das hat insbesondere den Charme, nicht durch
Unachtsamkeit an anderer Stelle umgangen werden zu können. Für die
Berechtigung brauche ich das aktuelle Login, und das ist in der
Session gespeichert. So weit, so gut.

Nun kommt es gelegentlich vor, dass auch Singletons in die Session
gelegt werden, und wenn die dann beim Wiederherstellen *vor* dem
Login initialisiert werden, schnappt die Berechtigungsprüfung zu.

An sich bräuchte ich an der Stelle gar nicht zu prüfen, denn das
wurde ja schon beim Schreiben in die Session erledigt. Es gibt aber
dummerweise auch noch a) Zugriffe komplett ohne Session (die haben
Zugriff) und b) Zugriffe mit Session, aber ohne Login (die haben
keinen Zugriff). Diese drei Fälle ließen sich sehr einfach
unterscheiden, wenn ich zum Zeitpunkt der Prüfung wüsste, ob das
Objekt gerade aus einer Session aufgeweckt wird oder nicht.

> Man könnte eventuuell das Problem auch umgekehrt angehen und
> sagen, man geht davon aus, dass man *in* einer Session ist, es sei
> denn man legt im Code fest, dass dies nicht so ist.

Ob ich in einer Session bin oder nicht, ist ja vergleichsweise
einfach festzustellen. Aber ob ich in einer (fertig restaurierten)
Session bin, die kein Login hat, oder ob ich gerade in einer (in
Aufbau befindlichen) Session bin, deren Login erst noch hinzugefügt
wird, das ist schwierig zu unterscheiden.

Servus,
   Stefan

-- 
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Stefan: fett werden mit Stil!
(Sloganizer)

[toc] | [prev] | [next] | [standalone]

#3957

Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) writes:

> On Fri, 09 Sep 2016 08:56:05 Karl Pflästerer wrote:
>> Kannst du das Problem genauer schildern, dass du lösen möchtest?
>
> Dann will mir ganz bestimmt wieder jemand ausreden, das zu tun, was
> ich mache :-)

Das kann geschehen.

>> Die betreffenden Objekte werden also nicht nur in Sessiondaten
>> gespeichert und aus diesen deserialisiert?
>
> Ich hänge mich gerade bei einer Reihe von Singletons in den
> Initialisierungscode, um dort eine Berechtigungsprüfung
> durchzuführen; das hat insbesondere den Charme, nicht durch
> Unachtsamkeit an anderer Stelle umgangen werden zu können. Für die
> Berechtigung brauche ich das aktuelle Login, und das ist in der
> Session gespeichert. So weit, so gut.
>
> Nun kommt es gelegentlich vor, dass auch Singletons in die Session
> gelegt werden, und wenn die dann beim Wiederherstellen *vor* dem
> Login initialisiert werden, schnappt die Berechtigungsprüfung zu.

[...]

> Ob ich in einer Session bin oder nicht, ist ja vergleichsweise
> einfach festzustellen. Aber ob ich in einer (fertig restaurierten)
> Session bin, die kein Login hat, oder ob ich gerade in einer (in
> Aufbau befindlichen) Session bin, deren Login erst noch hinzugefügt
> wird, das ist schwierig zu unterscheiden.


Also musst du entweder sicherstellen, dass die Sessiondaten in einer
festen Reihenfolge deserialisiert werden (ich hatte noch nie das
Problem, also weiß ich nicht, ob es nicht genügt, die umgekehrte
Reihenfolge beim Hinzufügen der Objekte in die Session einzuhalten),
oder du musst dich von deinem Automatismus verabschieden und eine
Methode/Funktion/whatever explizit aufrufen, die die Berechtigungen
prüft.
Diese festen Prüfungen gefallen mir nicht mehr so sehr (ich bin da eher
bei Python: "explizit is better than implicit"), da man im ersten
Augenblick meint, verhindert zu haben, das andere Entwickler (natürlich
immer nur andere :-; ) vergessen, Berechtigungen zu prüfen.
Bei Szenarien, wie du sie beschreibst, fallen einem diese Automatismen
dann auf die Füße.

  KP

[toc] | [prev] | [next] | [standalone]

#3958

On Fri, 09 Sep 2016 14:25:45 Karl Pflästerer wrote:
> > Ob ich in einer Session bin oder nicht, ist ja vergleichsweise
> > einfach festzustellen. Aber ob ich in einer (fertig
> > restaurierten) Session bin, die kein Login hat, oder ob ich
> > gerade in einer (in Aufbau befindlichen) Session bin, deren
> > Login erst noch hinzugefügt wird, das ist schwierig zu
> > unterscheiden.

> Also musst du entweder sicherstellen, dass die Sessiondaten in
> einer festen Reihenfolge deserialisiert werden (ich hatte noch nie
> das Problem, also weiß ich nicht, ob es nicht genügt, die
> umgekehrte Reihenfolge beim Hinzufügen der Objekte in die Session
> einzuhalten),

Hm. Ich könnte da jetzt ein paar Versuchsreihen starten, aber dann
könnte ich auch einfach Glück haben. Ich sähe nirgendwo, dass die
Reihenfolge der Variablen in der Session irgendwie garantiert wäre.

> [...] oder du musst dich von deinem Automatismus verabschieden und
> eine Methode/Funktion/whatever explizit aufrufen, die die
> Berechtigungen prüft.

Ganz schlecht...

> Diese festen Prüfungen gefallen mir nicht mehr so sehr (ich bin da
> eher bei Python: "explizit is better than implicit"), da man im
> ersten Augenblick meint, verhindert zu haben, das andere
> Entwickler (natürlich immer nur andere :-; ) vergessen,
> Berechtigungen zu prüfen.

In dem Fall geht's um eine strikte Trennung zwischen verschiedenen
Mandanten, und die ist einfach auf dieser Ebene viel besser
aufgehoben, als wenn man bei jedem Objekt und (schlimmer noch) bei
jeder Seite neuerlich darüber nachdenken muss, was jemand nun tun
darf oder nicht.

Momentan arbeite ich mit einem Workaround: Ist die Session leer,
gehe ich davon aus, dass sie gerade initialisiert wird und gebe
damit weitreichenden Zugriff.

Da es nur eine Hand voll Seiten gibt, die ohne Login aufgerufen
werden können, ist es noch halbwegs überschaubar, dort strengere
Sicherheitsmechanismen zu etablieren.

Aber sollte jemandem jetzt oder später noch zufällig eine Lösung für
das Problem unterkommen - etwas mehr Eleganz würde mich nicht
stören.

Servus,
   Stefan

-- 
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Stefan!? Ja! Denn schlauchen ist glanzvoller als latschen.
(Sloganizer)

[toc] | [prev] | [next] | [standalone]

#3960

Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) writes:

> On Fri, 09 Sep 2016 14:25:45 Karl Pflästerer wrote:
>> > Ob ich in einer Session bin oder nicht, ist ja vergleichsweise
>> > einfach festzustellen. Aber ob ich in einer (fertig
>> > restaurierten) Session bin, die kein Login hat, oder ob ich
>> > gerade in einer (in Aufbau befindlichen) Session bin, deren
>> > Login erst noch hinzugefügt wird, das ist schwierig zu
>> > unterscheiden.
>
>> Also musst du entweder sicherstellen, dass die Sessiondaten in
>> einer festen Reihenfolge deserialisiert werden (ich hatte noch nie
>> das Problem, also weiß ich nicht, ob es nicht genügt, die
>> umgekehrte Reihenfolge beim Hinzufügen der Objekte in die Session
>> einzuhalten),
>
> Hm. Ich könnte da jetzt ein paar Versuchsreihen starten, aber dann
> könnte ich auch einfach Glück haben. Ich sähe nirgendwo, dass die
> Reihenfolge der Variablen in der Session irgendwie garantiert wäre.

[...]

>
> Aber sollte jemandem jetzt oder später noch zufällig eine Lösung für
> das Problem unterkommen - etwas mehr Eleganz würde mich nicht
> stören.

Wie immer: "All problems in computer science can be solved by another
level of indirection, except of course for the problem of too many
indirections."

Ungetestet: Du könntest deine Objekte nicht direkt in die Session
schreiben, sondern sie *serialisiert* als Attribute eines Objektes
speichern (oder bei __sleep serialisieren). Dieses Objekt packst du in
die Session und in dessen __wakeup Methode deserialisiert du deine
Objekte in der gewünschten Reihenfolge.

Ob das eleganter ist? Ein wenig vielleicht.

  KP

[toc] | [prev] | [next] | [standalone]

#3962

On Fri, 09 Sep 2016 20:46:46 Karl Pflästerer wrote:
> Du könntest deine Objekte nicht direkt in die Session schreiben,
> sondern sie *serialisiert* als Attribute eines Objektes speichern
> (oder bei __sleep serialisieren). Dieses Objekt packst du in die
> Session und in dessen __wakeup Methode deserialisiert du deine
> Objekte in der gewünschten Reihenfolge.
 
> Ob das eleganter ist? Ein wenig vielleicht.

Ein bisschen schon, aber dann kann ich wieder das verwendete Framework
kübeln, das sich um derartige Dinge selbständig kümmert. Irgendetwas
ist halt immer :-/

Vielleicht fange ich tatsächlich einmal an, mich mit Extensions
auseinanderzusetzen, das könnte ich an ein paar zentralen Stellen
auch für Performance ganz gut brauchen.
 
Servus,
   Stefan

-- 
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Gerben mit Stefan - debil werden mit Eleganz.
(Sloganizer)

[toc] | [prev] | [next] | [standalone]

#3959

Am 09.09.2016 um 00:14 schrieb Stefan Froehlich:

> On Thu, 08 Sep 2016 14:21:28 Karl Pflästerer wrote:
>
>> Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) writes:
>>
>>> [...] kann ich irgendwie herausbekommen, ob ich mich gerade *im*
>>> Aufbau einer Session befinde, d.h. im Initialisierungscode von darin
>>> enthaltenen Objekten?
> 
>> Was ist, wenn du
>> http://php.net/manual/en/function.session-set-save-handler.php nutzt und
>> einen eigenen Sessionhandler definierst?
> 
> SessionHandler::read() wird aufgerufen, um die serialisierten Daten
> zu lesen. Dummerweise scheint die Initialisierung der geladenen
> Daten erst danach zu erfolgen, und ausserhalb der via Interface
> zugänglichen Methoden :-/

Ja, das ist tatsächlich so.  ::read() dient eben nur zum *Lesen* der
Daten, und soll eine *Zeichenkette* zurückliefern.  Die eigentliche
Deserialisierung übernimmt der festgelegte session.serialize_handler.
Dort kann aber nur ein per C Code vordefinierter Handler ausgewählt
werden.  Wenn Du die Möglichkeit hast, auf dem Server beliebige
Extensions zu installieren, dann könntest Du prinzipiell einen selbst
programmierten Handler per php_session_register_serializer()
registrieren, der z.B. vorübergehend eine globale Variable setzt, die
dann in __wakeup() geprüft werden kann.

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#3961

On Fri, 09 Sep 2016 19:39:19 Christoph M. Becker wrote:
> > SessionHandler::read() wird aufgerufen, um die serialisierten
> > Daten zu lesen. Dummerweise scheint die Initialisierung der
> > geladenen Daten erst danach zu erfolgen, und ausserhalb der via
> > Interface zugänglichen Methoden :-/
 
> Ja, das ist tatsächlich so.  ::read() dient eben nur zum *Lesen*
> der Daten, und soll eine *Zeichenkette* zurückliefern.  Die
> eigentliche Deserialisierung übernimmt der festgelegte
> session.serialize_handler.

An gibt es dort ja auch nicht mehr viel, was man sinnvoll tun
könnte. Für ein Flag, wie hier skizziert, wäre es ja auch lediglich
der Einhängepunkt, die Algorithmik selbst bliebe unverändert.

> Wenn Du die Möglichkeit hast, auf dem Server beliebige Extensions
> zu installieren, dann könntest Du prinzipiell einen selbst
> programmierten Handler per php_session_register_serializer()
> registrieren, [...]

Die Möglichkeit habe ich jederzeit. Die Frage ist eher: *Kann* ich
das?

Die notwendigen C-Kenntnisse sind vermutlich recht überschaubar,
aber wenn ich ein bisschen nach "create PHP extension" suche, stoße
ich über dutzende Konventionen, die man kennen müsste, und von denen
ich keine Ahnung habe :-/

Prinzipiell wäre das aber sicherlich die sauberste Lösung für das
Problem.

Servus,
   Stefan

-- 
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Königliche Programmierer bekommt die Ewigkeit: Stefan!
(Sloganizer)

[toc] | [prev] | [next] | [standalone]

#3963

Am 11.09.2016 um 18:02 schrieb Stefan Froehlich:

> On Fri, 09 Sep 2016 19:39:19 Christoph M. Becker wrote:
>
>> Wenn Du die Möglichkeit hast, auf dem Server beliebige Extensions
>> zu installieren, dann könntest Du prinzipiell einen selbst
>> programmierten Handler per php_session_register_serializer()
>> registrieren, [...]
> 
> Die Möglichkeit habe ich jederzeit. Die Frage ist eher: *Kann* ich
> das?
> 
> Die notwendigen C-Kenntnisse sind vermutlich recht überschaubar,
> aber wenn ich ein bisschen nach "create PHP extension" suche, stoße
> ich über dutzende Konventionen, die man kennen müsste, und von denen
> ich keine Ahnung habe :-/

Ja, leider sieht es mit Dokumentation bzgl. Extensions nicht so gut aus.
Im "Hacker Guide" findet sich ein bisschen was[1], aber das wurde noch
nicht für PHP 7 aktualisiert.

Andererseits müsste es ja zumindest fürs Erste gar keine Extension sein,
sondern nur ein paar kleine Anpassungen am Quellcode. Das wollte ich mir
gerade mal anschauen, und da sehe ich, dass das wohl gar nicht nötig
ist, da der relevante Code[2] wohl erst nach der Deserialisierung die
globale $_SESSION Variable setzt. Also könnte ein

  if (!isset($_SESSION)) {
    // session noch nicht fertig initialsiert
  }

genügen.

[1] <http://php.net/manual/en/internals2.structure.php>
[2]
<https://github.com/php/php-src/blob/PHP-7.0.11/ext/session/session.c#L903-L933>

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#3974

On Thu, 15 Sep 2016 15:25:56 Christoph M. Becker wrote:
> Andererseits müsste es ja zumindest fürs Erste gar keine Extension
> sein, sondern nur ein paar kleine Anpassungen am Quellcode.

Was tendenziell weniger glünstig wäre, weil ich mich dann um
allfällige Security-Updates selber kümmern müsste, anstatt mich
auf die (gute) Arbeit der Maintainer verlassen zu können. Aber:

> Das wollte ich mir gerade mal anschauen, und da sehe ich, dass das
> wohl gar nicht nötig ist, da der relevante Code[2] wohl erst nach
> der Deserialisierung die globale $_SESSION Variable setzt. Also
> könnte ein
> 
>   if (!isset($_SESSION)) {
>     // session noch nicht fertig initialsiert
>   }
> 
> genügen.

Das ist hübsch, denn das legitimiert sozusagen meinen Workaround
(wenn's keine Session gibt, wird schon alles passen).

Servus,
   Stefan

-- 
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Stefan, so fett. Mit dem Atem des Waldes!
(Sloganizer)

[toc] | [prev] | [next] | [standalone]

#3975

Am 02.10.2016 um 20:48 schrieb Stefan Froehlich:

> On Thu, 15 Sep 2016 15:25:56 Christoph M. Becker wrote:
>
>> […] Also könnte ein
>>
>>   if (!isset($_SESSION)) {
>>     // session noch nicht fertig initialsiert
>>   }
>>
>> genügen.
> 
> Das ist hübsch, denn das legitimiert sozusagen meinen Workaround
> (wenn's keine Session gibt, wird schon alles passen).

Verlassen würde ich mich auf Dauer nicht darauf, denn die
Implementierung könnte sich ändern. Zumindest solltest Du PHP-Updates
auf dieses Verhalten testen.

-- 
Christoph M. Becker

[toc] | [prev] | [standalone]

Back to top | Article view | de.comp.lang.php

csiph-web