AirMax: SESSION oder COOKIE?

Guten Morgen

Ich habe eine Frage an Euch. Aber zunächst kurz mein Anliegen:
Ich habe auf einer PHP-Startseite ein Bild, welches ich per Zufall laden will. Gestern habe ich dafür mal die COOKIE-Variante ausprobiert. Und sie hat funktioniert! Gut finde ich an den COOKIES, dass man ihre Lebensdauer bestimmen kann. Ich will, dass es nur solange gültig ist, bis der browser geschlossen wird. Aber was, wenn COOKIES deaktiviert sind. Entweder bestimmt man dann ein Bild, welches definitiv geladen wird oder man steigt gleich auf SESSION um. Ich habe SESSIONS aber noch nie benutzt und wollte fragen, ob das eine gute Alternative für mein Vorhaben ist?
Und gleich noch ein Problem. Es trat schon bei der COOKIE-Variante auf und wird bei SESSION wahrscheinlich auch bestehen bleiben: Wenn ich die Seite das erste mal öffne, paasiert nichts. Es wird kein Bild geladen. Das liegt daran, dass zunächst das COOKIE gespeichert werden muss. Erst beim erneuten Öffnen der Seite wird das COOKIE ausgelesen. Muss ich nun das PHP-Skript zum Speichern des Cookies als "leeres" Dokument voranslten, bevor der eigentlich Webauftritt in der nächsten Seite beginnt?

Danke für eure Hilfe

AirMax

  1. Hello,

    [...] Aber was, wenn COOKIES deaktiviert sind. Entweder bestimmt man dann ein Bild, welches definitiv geladen wird oder man steigt gleich auf SESSION um. Ich habe SESSIONS aber noch nie benutzt und wollte fragen, ob das eine gute Alternative für mein Vorhaben ist?

    Sessions funktionieren per HTTP/HTTPS auch nur mit Cookies gut. Alle anderen Lösungen sind bestenfalls ausreichend bis mangelhaft. Einzige Ausnahme vielelicht, wenn man Basic Authentication ohnehin voraussetzen würde, dann kann man noch eine befriedengende Lösung für eine Session ohne Cookies erreichen.

    Liebe Grüße aus dem schönen Oberharz

    Tom vom Berg

    --
    Nur selber lernen macht schlau
    http://bergpost.annerschbarrich.de
    1. Hello,

      [...] Aber was, wenn COOKIES deaktiviert sind. Entweder bestimmt man dann ein Bild, welches definitiv geladen wird oder man steigt gleich auf SESSION um. Ich habe SESSIONS aber noch nie benutzt und wollte fragen, ob das eine gute Alternative für mein Vorhaben ist?

      Sessions funktionieren per HTTP/HTTPS auch nur mit Cookies gut. Alle anderen Lösungen sind bestenfalls ausreichend bis mangelhaft.

      und das Problem dabei ist dann, dass man nie weiß, dass der Client keine Kekse akzeptiert (weil man ihn ja genau deswegen nicht "identifizieren" kann).

      Ich halte das übrigens für einen "Designfehler", dass Sessions von Cookies, und somit wieder von Client-Einstellungen abhängen.

      Gruß Gunther

      1. Hello,

        Ich halte das übrigens für einen "Designfehler", dass Sessions von Cookies, und somit wieder von Client-Einstellungen abhängen.

        Responses sind auch von der Aktivität des Clients abhängig. Wenn der keinen Request absendet, sollte er tunlichst auch keine Response erhalten. Ist das dann auch ein Designfehler?

        Ich bin der Meinung, dass das eher "works as designed" ist. Die Webentwickler müssen sich nur langsam mal von der irrigen Meinung frei machen, dass sie eine Leistung auch dann anbieten müssen, wenn der Client diese gar nicht unterstützen will. Das Web ist ein DIALOGSYSTEM und kein Broadcast-Medium, bei der alle Nutzer immer gleichartig berieselt werden müssen.

        Wer nicht will, der hat schon, oder ist eben einfach zu blöd!

        Liebe Grüße aus dem schönen Oberharz

        Tom vom Berg

        --
        Nur selber lernen macht schlau
        http://bergpost.annerschbarrich.de
        1. Hi Tom.

          Ich bin der Meinung, dass das eher "works as designed" ist.

          Dem stimme ich zu. Bei jeder Art von Session-Mechanismus ist man nun mal darauf angewiesen, dass der Client mitspielt und sich - wie auch immer - zu erkennen gibt. Wenn man es als Designfehler bezeichnen mag, dann vom HTTP, aber sicher nicht von PHP.

          Die Webentwickler müssen sich nur langsam mal von der irrigen Meinung frei machen, dass sie eine Leistung auch dann anbieten müssen, wenn der Client diese gar nicht unterstützen will.

          Ich möchte aber gerade mal dran erinnern, dass PHP-Sessions auch ohne Cookies funktionieren. Und der hier besprochene Anwendungsfall ist einer, in dem die damit verbundenen Sicherheitseinschränkungen unproblematisch sind.

          Viele Grüße,
          der Bademeister

          1. Hello,

            Ich möchte aber gerade mal dran erinnern, dass PHP-Sessions auch ohne Cookies funktionieren. Und der hier besprochene Anwendungsfall ist einer, in dem die damit verbundenen Sicherheitseinschränkungen unproblematisch sind.

            Unabhängig davon, das hier PHP benutzt werden soll, funktionieren Sessions bei HTTP / HTTPS nur vernünftig, wenn Cookies eingesetzt werden. Anders ist das bisher nicht implementiert.

            Und wer die Leistungen des Systems in Anspruch nehmen will, der muss dann eben Sessions und dafür möglichst Cookies akzeptieren. Selbstverstänlich gibt es andere Möglichkeiten. Cookies wären aber nicht erfunden worden un dhaben sich bis heute gehalten, wenn die anderen Möglichkeiten schon befriedigend gewesen wären.

            Liebe Grüße aus dem schönen Oberharz

            Tom vom Berg

            --
            Nur selber lernen macht schlau
            http://bergpost.annerschbarrich.de
          2. Ich möchte aber gerade mal dran erinnern, dass PHP-Sessions auch ohne Cookies funktionieren. Und der hier besprochene Anwendungsfall ist einer, in dem die damit verbundenen Sicherheitseinschränkungen unproblematisch sind.

            Das stimmt. Werde mir Session mal zu Gemüte führen...

            Gruß

        2. Hello Tom,

          ich stimme dir ja weitestgehend zu und sehe das zumindest ähnlich.

          Ich halte das übrigens für einen "Designfehler", dass Sessions von Cookies, und somit wieder von Client-Einstellungen abhängen.

          Responses sind auch von der Aktivität des Clients abhängig. Wenn der keinen Request absendet, sollte er tunlichst auch keine Response erhalten. Ist das dann auch ein Designfehler?

          Ich bin der Meinung, dass das eher "works as designed" ist. Die Webentwickler müssen sich nur langsam mal von der irrigen Meinung frei machen, dass sie eine Leistung auch dann anbieten müssen, wenn der Client diese gar nicht unterstützen will. Das Web ist ein DIALOGSYSTEM und kein Broadcast-Medium, bei der alle Nutzer immer gleichartig berieselt werden müssen.

          Prinzipiell schon richtig, aber ich frage mich dabei halt nur immer, welche Dinge wirklich dem Client, bzw. seiner Entscheidung überlassen werden müssen. Insbesondere dann, wenn diese Entscheidung eigentlich keinen Unterschied für den Client macht, wohl aber für den zu betreibenden Aufwand des Seitenautors.

          Warum muss ich solche (anonymen) Informationen wie bspw. die des UA, meiner IP-Adresse etc. absichtlich "verfälschen" oder unterdrücken?

          Wer nicht will, der hat schon, oder ist eben einfach zu blöd!

          Ja, prinzipiell würde ich dir hier auch zustimmen.

          Worum es mir aber im Wesentlichen geht ist, dass es imho nicht unbedingt bei allen Dingen sinnvoll ist, diese der Entscheidung des Clients zu überlassen, denn schließlich hat er mit der Anforderung meiner Seite ja schon mal eine grundsätzliche Entscheidung getroffen.

          Und wieviele potentielle Sicherheitslücken entstehen, bzw. existieren nur deshalb?

          Gruß Gunther

          1. Hello,

            Warum muss ich solche (anonymen) Informationen wie bspw. die des UA, meiner IP-Adresse etc. absichtlich "verfälschen" oder unterdrücken?

            Wenn Du Deine IP-Adresse verfälschen würdest, würdest Du keine Antwort erhalten.

            Liebe Grüße aus dem schönen Oberharz

            Tom vom Berg

            --
            Nur selber lernen macht schlau
            http://bergpost.annerschbarrich.de
            1. Hello,

              Warum muss ich solche (anonymen) Informationen wie bspw. die des UA, meiner IP-Adresse etc. absichtlich "verfälschen" oder unterdrücken?

              Wenn Du Deine IP-Adresse verfälschen würdest, würdest Du keine Antwort erhalten.

              das war ja klar, dass das kommen musste ...! ;-)

              Siehe (u.a.): http://de.wikipedia.org/wiki/Anonymizer ff.

              Gruß Gunther

              1. Hello,

                Warum muss ich solche (anonymen) Informationen wie bspw. die des UA, meiner IP-Adresse etc. absichtlich "verfälschen" oder unterdrücken?

                Wenn Du Deine IP-Adresse verfälschen würdest, würdest Du keine Antwort erhalten.
                das war ja klar, dass das kommen musste ...! ;-)

                Siehe (u.a.): http://de.wikipedia.org/wiki/Anonymizer ff.

                Ja und? Damit hast Du doch nicht DEINE IP-Adresse verfälscht, sondern versteckst sie nur hinter einem zusätzlichen Dienst. Dabei verlässt Du dich darauf, dass dieser dann nicht überwacht wird, denn dieser Dienst muss sich für die Ofenzeit des Requests auf jeden FALL wieder DEINE IP-Adresse merken.

                Liebe Grüße aus dem schönen Oberharz

                Tom vom Berg

                --
                Nur selber lernen macht schlau
                http://bergpost.annerschbarrich.de
                1. Hello,

                  Warum muss ich solche (anonymen) Informationen wie bspw. die des UA, meiner IP-Adresse etc. absichtlich "verfälschen" oder unterdrücken?

                  Wenn Du Deine IP-Adresse verfälschen würdest, würdest Du keine Antwort erhalten.
                  das war ja klar, dass das kommen musste ...! ;-)

                  Siehe (u.a.): http://de.wikipedia.org/wiki/Anonymizer ff.

                  Ja und? Damit hast Du doch nicht DEINE IP-Adresse verfälscht, sondern versteckst sie nur hinter einem zusätzlichen Dienst.

                  Deshalb stand da ja auch nicht nur "verfälschen", sondern "verfälschen oder unterdrücken", wobei hier 'unterdrücken' mit 'verstecken' gleichzusetzen ist.

                  Außerdem war es nur als_ein_Beispiel gedacht. Wenn du es als nicht passend/ geeignet ansiehst, dann streich' es einfach. ;-)

                  Entscheidend ist eh die Problematik ansich und nicht ein einzelnes Beispiel. ;-)

                  Gruß Gunther

    2. Hi,

      Sessions funktionieren per HTTP/HTTPS auch nur mit Cookies gut.

      Wir haben keinerlei Probleme mit unseren Sessions - und die werden ohne Cookie gehalten.
      Und wir sprechen (zumindest zu dieser Jahreszeit) hier von mehreren zig Tausend Sessions. Pro Stunde.

      Erklär mir doch bitte mal, wieso alle diese Sessions wunderbar funktionieren, wo sie doch keine Cookies verwenden!

      cu,
      Andreas

      --
      Warum nennt sich Andreas hier MudGuard?
      O o ostern ...
      Fachfragen per Mail sind frech, werden ignoriert. Das Forum existiert.
      1. Hello,

        Sessions funktionieren per HTTP/HTTPS auch nur mit Cookies gut.

        Wir haben keinerlei Probleme mit unseren Sessions - und die werden ohne Cookie gehalten.
        Und wir sprechen (zumindest zu dieser Jahreszeit) hier von mehreren zig Tausend Sessions. Pro Stunde.

        Erklär mir doch bitte mal, wieso alle diese Sessions wunderbar funktionieren, wo sie doch keine Cookies verwenden!

        Dann erkläre Du mir bitte, wie ihr das macht.
        Sollte es über SID in der URL/URi sein, ist das nicht gut, sondern ausreichend.
        Die SID hat in der URL/URi nichts verloren...

        Liebe Grüße aus dem schönen Oberharz

        Tom vom Berg

        --
        Nur selber lernen macht schlau
        http://bergpost.annerschbarrich.de
  2. Hi AirMax.

    Ich habe auf einer PHP-Startseite ein Bild, welches ich per Zufall laden will. Gestern habe ich dafür mal die COOKIE-Variante ausprobiert.

    Die Cookie-Variante, um ein Bild per Zufall zu laden? Was heißt das?

    Gut finde ich an den COOKIES, dass man ihre Lebensdauer bestimmen kann.

    Gut finde ich an Cookies, dass man ihre Lebensdauer bestimmen kann, wenn man der Client ist. Und dass der sendende Webserver lediglich einen Vorschlag über die Lebensdauer unterbreiten kann.

    Ich will, dass es nur solange gültig ist, bis der browser geschlossen wird. Aber was, wenn COOKIES deaktiviert sind. Entweder bestimmt man dann ein Bild, welches definitiv geladen wird [...]

    Man könnte irgendwie abhängig von der Urzeit serverseitig jeweils ein Bild als "aktiv" bestimmen, das eine gewisse Zeit lang (ein Tag, ein Stunde, ...) dasjenige Bild ist, das gesendet wird, wenn keine Cookies vorhanden sind. Das könnte das angestrebte Ziel ganz gut imitieren.

    oder man steigt gleich auf SESSION um. Ich habe SESSIONS aber noch nie benutzt und wollte fragen, ob das eine gute Alternative für mein Vorhaben ist?

    Ja, das ist es. Es umgeht das Problem, dass der User u.U. keine Cookies zulässt.

    Und gleich noch ein Problem. Es trat schon bei der COOKIE-Variante auf und wird bei SESSION wahrscheinlich auch bestehen bleiben: Wenn ich die Seite das erste mal öffne, paasiert nichts.

    In der Cookie Variante: Beim erstan Aufruf, wenn noch kein Cookie vom Client gesendet wurde, dann wählst Du das Bild aus und schreibst dessen Pfad sowohl ins Cookie als auch ins ausgelieferte Dokument (als "scr"-Wert des Titelbildes). Das ist unproblematisch, oder?

    In der Session-Variante steht der Pfad ohnehin nicht im Cookie. Das ändert aber nichts an der Vorgehensweise der Auswahl des Bildes.

    Viele Grüße,
    der Bademeister

    1. Hello,

      Ich habe auf einer PHP-Startseite ein Bild, welches ich per Zufall laden will. Gestern habe ich dafür mal die COOKIE-Variante ausprobiert.

      Die Cookie-Variante, um ein Bild per Zufall zu laden? Was heißt das?

      vermutlich, dass das Bild zwar zufällig aus einer Menge ausgewählt werden soll, die aber mit jedem request um das gerade angezeigte vermindert wird? Damit würde sichergestellt werden, dass der Besucher nicht bei jedem seiner Request doch "zufällig" dasselbe Bild angezeigt bekommt...

      Ich rate das jetzt mal, messe meiner Vermtuung eber eine relativ hohe Trefferwahrscheinlichkeit bei, weil der Anwendungsfall eine der häufigen Standardanforderungen an Zufallsbilder beschreibt.

      Liebe Grüße aus dem schönen Oberharz

      Tom vom Berg

      --
      Nur selber lernen macht schlau
      http://bergpost.annerschbarrich.de
    2. Hi Bademeister

      Ich habe auf einer PHP-Startseite ein Bild, welches ich per Zufall laden will. Gestern habe ich dafür mal die COOKIE-Variante ausprobiert.

      Die Cookie-Variante, um ein Bild per Zufall zu laden? Was heißt das?

        
      <?php  
      $zufall=rand(1,10);  
      setcookie("teaser",$zufall,0);  
      $cookie=$_COOKIE["teaser"];  
      echo "...Pfad/$cookie.jpg";  
      ?>
      

      Man könnte irgendwie abhängig von der Urzeit serverseitig jeweils ein Bild als "aktiv" bestimmen, das eine gewisse Zeit lang (ein Tag, ein Stunde, ...) dasjenige Bild ist, das gesendet wird, wenn keine Cookies vorhanden sind. Das könnte das angestrebte Ziel ganz gut imitieren.

      Ja, das habe ich früher so mit FLASH so gemacht. Meine Überlegung ist, dass das Bild auf der Startseite immer das gleichr ist, solange der User seinen Browser geöffnet hat. Das schafft Orientierung und Abwechslung von "Sitzung" zu "Sitzung" zugleich.

      Und gleich noch ein Problem. Es trat schon bei der COOKIE-Variante auf und wird bei SESSION wahrscheinlich auch bestehen bleiben: Wenn ich die Seite das erste mal öffne, paasiert nichts.

      In der Cookie Variante: Beim erstan Aufruf, wenn noch kein Cookie vom Client gesendet wurde, dann wählst Du das Bild aus und schreibst dessen Pfad sowohl ins Cookie als auch ins ausgelieferte Dokument (als "scr"-Wert des Titelbildes). Das ist unproblematisch, oder?

      Meine Überlegung war mit IF zu überprüfen:

        
      <?php  
      $zufall=rand(1,10);  
      setcookie("teaser",$zufall,0);  
      $cookie=$_COOKIE["teaser"];  
        
      if ($cookie = "")  
        {echo "...Pfad/1.jpg";}  
      else  
        {echo "...Pfad/$cookie.jpg";}  
      ?>
      

      Gruß
      AirMax

      1. Hi,

        <?php
        $zufall=rand(1,10);
        setcookie("teaser",$zufall,0);
        $cookie=$_COOKIE["teaser"];
        echo "...Pfad/$cookie.jpg";
        ?>

          
        Dir ist aber schon klar, dass du einen gerade erst gesetzten Cookie nicht aus $\_COOKIE auslesen kannst?  
          
        MfG ChrisB  
          
        
        -- 
        Light travels faster than sound - that's why most people appear bright until you hear them speak.
        
        1. Dir ist aber schon klar, dass du einen gerade erst gesetzten Cookie nicht aus $_COOKIE auslesen kannst?

          Ja, das ist ja genau das Problem. Ich müsste das Cookie schon früher setzen. Aber das geht nicht, da es bereits die Index-Seite betrifft...

          Gruß

          1. Ja, das ist ja genau das Problem. Ich müsste das Cookie schon früher setzen. Aber das geht nicht, da es bereits die Index-Seite betrifft...

            Oder ich mach es wie bereits angekündigt, dass ich ein Cookie setze, bevor die eigentliche Hauptseite geöffnet wird. Ich glaube fast, dass es gar keine andere Möglichkeit dafür gibt. Oder gleich auf den Cookie-Kram mit Zufallbild verzichten.

            Gruß

          2. Hi,

            Dir ist aber schon klar, dass du einen gerade erst gesetzten Cookie nicht aus $_COOKIE auslesen kannst?

            Ja, das ist ja genau das Problem. Ich müsste das Cookie schon früher setzen.

            Nein, du müsstest lediglich die Logik anders aufbauen.

            MfG ChrisB

            --
            Light travels faster than sound - that's why most people appear bright until you hear them speak.
            1. Nein, du müsstest lediglich die Logik anders aufbauen.

              Kannst Du mir dabei ein bißchen auf die Sprünge helfen?

              Danke!

              1. Hi,

                Nein, du müsstest lediglich die Logik anders aufbauen.

                Kannst Du mir dabei ein bißchen auf die Sprünge helfen?

                Wenn kein Cookie übermittelt wurde, ermittle im Script einen neuen Zufallswert. Setze einen Cookie mit diesem.
                Wenn ein Wert per Cookie übergeben wurde, nutze diesen, statt gerade ermitteltem Zufallswert.

                MfG ChrisB

                --
                Light travels faster than sound - that's why most people appear bright until you hear them speak.
                1. Wenn kein Cookie übermittelt wurde, ermittle im Script einen neuen Zufallswert. Setze einen Cookie mit diesem.
                  Wenn ein Wert per Cookie übergeben wurde, nutze diesen, statt gerade ermitteltem Zufallswert.

                  Klingt gut. Werde ich mal probieren.

                  Danke für Deine Hilfe

                2. Hi ChrisB

                  Wenn kein Cookie übermittelt wurde, ermittle im Script einen neuen Zufallswert. Setze einen Cookie mit diesem.
                  Wenn ein Wert per Cookie übergeben wurde, nutze diesen, statt gerade ermitteltem Zufallswert.

                  Hab's probiert und es funktioniert. Es gibt halt nur einen kleinen Schönheitsfehler, wenn cookies deaktiviert sind. Dann verwendet der browser beim wiederholten Besuch der Startseite IMMER einen neuen Zufallswert:

                    
                  <?php  
                  $cookie=$_COOKIE["teaser"];  
                  $zufall=rand(1,6);  
                    
                  if (empty($cookie)) {  
                      setcookie('teaser',$zufall,0);  
                      echo $zufall;  
                  }  
                  else {  
                      echo $cookie;  
                  }  
                  ?>  
                  
                  

                  Aber damit werde ich wohl leben müssen.

                  Gruß
                  AirMax

                  1. Hello,

                    Hab's probiert und es funktioniert. Es gibt halt nur einen kleinen Schönheitsfehler, wenn cookies deaktiviert sind. Dann verwendet der browser beim wiederholten Besuch der Startseite IMMER einen neuen Zufallswert:

                    <?php
                    $cookie=$_COOKIE["teaser"];
                    $zufall=rand(1,6);

                    if (empty($cookie)) {
                        setcookie('teaser',$zufall,0);
                        echo $zufall;
                    }
                    else {
                        echo $cookie;
                    }
                    ?>

                    
                    > Aber damit werde ich wohl leben müssen.  
                      
                    Du könntest noch eine schmutzige Lösung verwenden, die aber in Deinem Fall vermutlich ausreichend bis befriedigend sein kann: Merke Dir auf dem Server einfach die IP des Clients eine Weile. Solange sie innerhalb einer gewissen Zeit wieder einen Request auslöst, bleibt sie in der Liste. Ist die Wartezeit überschritten, fliegt sie beim nächsten Zugriff raus, bzw. bekommt ein neues Zufallsbild zugewiesen.  
                      
                    Da hier weder Sicherheit noch Exaktheit gefragt ist, wird das ausnahmsweise zulässig sein, so vorzugehen... In den meisten anderen Fällen ist es eine dumme Idee.  
                      
                    Einiger Wermutstropfen: bei Usern, die hinter einem Anbieter sitzen, wie z.B. AOL (Gibt es die eigentlich noch? Ich habe schon so lange keine Skandale mehr vernommen), der bei jedem Request die IP innerhalb des Netzsegmentes neu auswürfelt, funktioniert es nicht wie vorgesehen.  
                      
                    Dass Leute, die hinter einem Proxy o.ä. sitzen dann aalle dasselebe Bild angezeigt bekommen, stört ja wahrscheinlich nicht so sehr...  
                      
                      
                      
                      
                      
                    Liebe Grüße aus dem schönen Oberharz  
                      
                      
                    Tom vom Berg  
                    ![](http://selfhtml.bitworks.de/Virencheck.gif)  
                      
                    
                    -- 
                    Nur selber lernen macht schlau  
                    <http://bergpost.annerschbarrich.de>  
                      
                    
                    
                    1. Hi Tom

                      Du könntest noch eine schmutzige Lösung verwenden, die aber in Deinem Fall vermutlich ausreichend bis befriedigend sein kann: Merke Dir auf dem Server einfach die IP des Clients eine Weile. Solange sie innerhalb einer gewissen Zeit wieder einen Request auslöst, bleibt sie in der Liste. Ist die Wartezeit überschritten, fliegt sie beim nächsten Zugriff raus, bzw. bekommt ein neues Zufallsbild zugewiesen.

                      Das wäre noch eine Möglichkeit. Habe zwar noch nie davon gehört, würde da aber bestimmt was zu finden...

                      Da hier weder Sicherheit noch Exaktheit gefragt ist, wird das ausnahmsweise zulässig sein, so vorzugehen.

                      Ja. nichts anspruchsvolles!

                      Dass Leute, die hinter einem Proxy o.ä. sitzen dann aalle dasselebe Bild angezeigt bekommen, stört ja wahrscheinlich nicht so sehr...

                      Ha, ha ... nee, wahrlich nicht.

                      Liebe Grüße aus dem schönen Oberharz

                      Grüße in den Harz
                      AirMax

                      1. Hello,

                        Das wäre noch eine Möglichkeit. Habe zwar noch nie davon gehört, würde da aber bestimmt was zu finden...

                        Wenn die Anzahl der Zugriffe pro Sekunde nicht zu groß wird, machst Du das am einfachsten mit einem Array, das für die Speicherung serialiert wird.

                        Löse die Gesamtaufgabe in überschaubare Funktionen auf, dann kannst Du die einzelnen Funktionen immer wieder verwenden.

                        Liebe Grüße aus dem schönen Oberharz

                        Tom vom Berg

                        --
                        Nur selber lernen macht schlau
                        http://bergpost.annerschbarrich.de
                        1. »» »» Das wäre noch eine Möglichkeit. Habe zwar noch nie davon gehört, würde da aber bestimmt was zu finden...

                          Wenn die Anzahl der Zugriffe pro Sekunde nicht zu groß wird, machst Du das am einfachsten mit einem Array, das für die Speicherung serialiert wird.

                          Löse die Gesamtaufgabe in überschaubare Funktionen auf, dann kannst Du die einzelnen Funktionen immer wieder verwenden.

                          Ok, danke für den Tipp. Werd's mal ausprobieren.

                          Gruß

                          AirMax

                    2. Hallo,

                      Dass Leute, die hinter einem Proxy o.ä. sitzen dann aalle dasselebe Bild angezeigt bekommen, stört ja wahrscheinlich nicht so sehr...

                      auch hier ließe sich die Wahrscheinlichkeit noch ein wenig drücken, wenn man neben der IP-Adresse noch andere (relativ) individuelle Request-Angaben zum Vergleich heranzieht. Beispielsweise könnte man aus $_SERVER['HTTP_USER_AGENT'] und $_SERVER['HTTP_ACCEPT(_*)?'] eine einfach Quersumme bilden.

                      Interessanter wären da schon andere Geschichten, die im Allgemeingebrauch ausscheiden. HTTP 1.1 setzt auf persistente Verbindungen, die prinzipiell (bis zum TCP-Time-Out) als Basis einer eindeutigen session- und cookie-unabhängigen Wiederkennung dienen könnten. Leider, leider scheitert dies allgemein an derzeitigen Webservern und Browsern. Kein mir bekannter Webserver unterstützt verbindungsbezogenes computing. Auch Webbrowser wie FireFox machen die Leitungen nach konfigurierter Request-Anzahl dicht. Schade...

                      Gruß aus Berlin!
                      eddi

  3. Mahlzeit,

    Und gleich noch ein Problem. Es trat schon bei der COOKIE-Variante auf und wird bei SESSION wahrscheinlich auch bestehen bleiben: Wenn ich die Seite das erste mal öffne, paasiert nichts. Es wird kein Bild geladen. Das liegt daran, dass zunächst das COOKIE gespeichert werden muss. Erst beim erneuten Öffnen der Seite wird das COOKIE ausgelesen. Muss ich nun das PHP-Skript zum Speichern des Cookies als "leeres" Dokument voranslten, bevor der eigentlich Webauftritt in der nächsten Seite beginnt?

    Da hilft Ajax, geht so: User fordert Seite an, Cookie wird lokal gespeichert, sofern User das erlaubt [1]. Ein Ajax-Request geht raus zurück an den Server und schickt den Keks mit, auf dem Server wird geprüft, ob alles OK. In der jetzt folgenden Response steht drin, dass das Bild geladen werden kann.

    [1] _immer_ prüfen!!!

    Viele Grüße,
    Horst Krümelmonster

  4. Hi,

    Ich habe auf einer PHP-Startseite ein Bild, welches ich per Zufall laden will. Gestern habe ich dafür mal die COOKIE-Variante ausprobiert. Und sie hat funktioniert! Gut finde ich an den COOKIES, dass man ihre Lebensdauer bestimmen kann. Ich will, dass es nur solange gültig ist, bis der browser geschlossen wird. Aber was, wenn COOKIES deaktiviert sind.

    Ja was denn dann?

    Welcher Nachteil entsteht dem Nutzer bei deiner Umsetzung dadurch?

    MfG ChrisB

    --
    Light travels faster than sound - that's why most people appear bright until you hear them speak.
    1. Hi ChrisB

      Welcher Nachteil entsteht dem Nutzer bei deiner Umsetzung dadurch?

      Es wird dann lediglich kein Bild angezeigt. Deswegen habe ich mir überlegt, dass man eine IF-Abfrage machen müsste. Wenn ein Cookie da ist, soll er den Wert des Cookies verwenden. Ween keins da ist, dann soll er einen fixen Werten verwenden, dem ich ihm angebe. Das blöde ist nur, dass das nicht richtig funktionieren wird, denn das Cookie soll nur eine "browser-Sitzung" lang gültig sein. Und IMMER, wenn ich den browser neu starte, ist KEIN Cookie da. Also wird er immer den Wert verwenden, dem ich ihm angebe...

      Gruß

      1. Hi,

        Das blöde ist nur, dass das nicht richtig funktionieren wird, denn das Cookie soll nur eine "browser-Sitzung" lang gültig sein. Und IMMER, wenn ich den browser neu starte, ist KEIN Cookie da.

        Das Problem hast du unabhängig davon, wie lange der Cookie vom Client gespeichert wird.
        Der "erste" Request wird immer einer sein, der keinen Cookie mitschickt.

        Also wird er immer den Wert verwenden, dem ich ihm angebe...

        Auch wenn kein Cookie mitgesendet wurde, kannst du trotzdem versuchen, einen zu setzen.
        Wenn er bei nachfolgenden Requests dann wieder mitgeschickt wird, kannst du ihn auswerten.

        MfG ChrisB

        --
        Light travels faster than sound - that's why most people appear bright until you hear them speak.
  5. Hallo AirMax,

    Tom hatte sich ja schon dafür ins Zeug gelegt, Cookies als die Wahl des Mittels herauszustellen. Daher will ich nur zwei Sachen anmerken:

    Im Gebrauch mit Cookies sollte man immer eine Pfadangabe nutzen, was leider immer wieder falsch gemacht wird. Sie werden sonst völlig sinnlos mit jedem request dem Server angeboten. Das ist zwar weiter nicht tragisch, nur ist es nicht ressourcen-schonend, weil es unnötigen Datenverkehr erzeugt. Bei größer werdenden Projekten kann man so auch Überschneidungen von Cookies vermeiden. Die Pfadangabe ist insoweit ähnlich verschiedener Programmiersprachen namensraumgestaltend. Das bedeutet eben auch, dass man sich beim Gebrauch auch Gedanken über die Strukturierung seines Webprojektes machen sollte, was die Verzeichnisstruktur anbelangt. Darüber hinaus ist für Deine spezielle Aufgabe der Keks tatsächlich nicht für die auszuliefernden Dokumente von Bedeutung sondern für die Wahl der Bilder und sollte auch nur dort gesendet werden. Das hat Konsequenzen für das Konzept der Programmlogik.
     Während man allgemein nur innerhalb der Scripte, die das eigentliche Dokument ausgeben sollen, auf den Cookie prüfen würde und dementsprechend eine URL-Angabe im HTML ändern würde, sollte man serverseitig mittels des Cookies und der URL andere Inhalte (also andere Bilder) ausliefern. Ich schreibe das deswegen so allgemein, weil PHP/Scripte hier nicht die einzige Variante sein muss. Dazu später noch ein Beispiel. Leider hat das Verfahren auch ein Schönheitsfehler, denn entsprechende Zusatzangaben, die mit den den jeweiligen Bildern einhergehen (alt-Attribut im <img>-Element), können dann dynamisch nicht angepasst werden.
     Es sei folgende Verzeichnisstruktur gegeben:

    /
      |
      |-css/
      |
      |-js/
      |
      |-bilder/
      |  |
      |  |-0.jpg
      |  |
      |  |-1.jpg
      |  |
      |  |-2.jpg
      |  |
      |  |-.htaccess
      |  |
      |  -img.php   |   -dokument.html

    In der dokument.html sollte also die URL zum sich wechselnden Bild hardcodiert werden (z. B. <img src="bilder/img.php" alt="blabla"/>). Die tatsächliche Kontrolle und das Setzen des Cookies obliegt nunmehr der img.php, die nach Auswertung eines der Bilder serviert. Mit der Pfadangabe im Keks werden Cookies nur an Anfragen an /bilder/ gesendet. Weder restliche Scripte, Dokumente, noch andere Verzeichnisse werden mit den Keksen versorgt. Jedoch ist PHP für das einfache Ausgeben von einem entsprechenden Conten-Type-Header, vielleicht noch einer Cache-Angabe und dem Dateninhalt der einzelnen Dateien überdimensioniert. Das kann beispielsweise der Apache mit mod_rewrite ganz alleine und ohne PHP. Der oben angegebenen Verzeichnisstruktur entsprechend sieht die .htaccess dann so aus:

    RewriteCond %{HTTP_COOKIE} (name=2|^$)  
    RewriteRule ^img.php$      0.jpg       [L,CO=name:0:domainname:10:/bilder/]  
      
    RewriteCond %{HTTP_COOKIE} name=0  
    RewriteRule ^img.php$      1.jpg       [L,CO=name:1:domainname:10:/bilder/]  
      
    RewriteCond %{HTTP_COOKIE} name=1  
    RewriteRule ^img.php$      2.jpg       [L,CO=name:2:domainname:10:/bilder/]
    

    Die zweite Sache, die ich noch ansprechen wollte, betrifft Deine spezielle Aufgabenstellung. Da es in Deinem Fall nicht sicherheitsrelevant ist, kann zugunsten 100%er Funktionalität, was Cookies eben nicht bieten können auf Session in der Form gesetzt werden, dass die Session-ID im URL abgelegt wird. Auch für diese Variante ist man nicht auf PHP/Scripte angewiesen.

    Gruß aus Berlin!
    eddi

    1. Hallo Eddi,

      VIELEN Dank für Deine umfangreiche Antwort. Werde mich mal in Ruhe bei Gelegenheit damit auseinadersetzen. Falls ich noch Fragen haben sollte, werde ich mich wieder bei Dir melden!

      Gruss in die Heimat

    2. Hallo Edgar,

      ich habe mir jetzt mal Zeit genommen, um das zu verarbeiten, was Du da schreibst. Ich muss sagen, dass ich nicht alles von Anfang an verstehe. Manches erschliesst sich mir auch überhaupt nicht. Aber das liegt eben daran, dass ich überhaupt nicht vom Fach bin. Deswegen suche ich mir eben immer einfache Lösungswege, die ich aber dafür verstehe.

      Du hast folgendes geschrieben:

      In der dokument.html sollte also die URL zum sich wechselnden Bild hardcodiert werden (z. B. <img src="bilder/img.php" alt="blabla"/>). Die tatsächliche Kontrolle und das Setzen des Cookies obliegt nunmehr der img.php, die nach Auswertung eines der Bilder serviert. Mit der Pfadangabe im Keks werden Cookies nur an Anfragen an /bilder/ gesendet. Weder restliche Scripte, Dokumente, noch andere Verzeichnisse werden mit den Keksen versorgt.

      Das finde ich einen ganz interessanten Ansatz. Das mag bei meinem Miniprojekt zwar nicht so von grosser Bedeutung sein, aber bei anderen Geschichten wäre das eine super Idee. Was mir daran gefällt ist, dass der ganze PHP-Prozess nur das IMG-Element (oder bei mir das Object-Element) betrifft. Es wird also nur auf dieses Element bezogen und nicht, wie Du ja bereits sagtest, global auf das gesamte "Projekt". Ausserdem bin ich ein Fan von dynamischen Elementen, die es mir gestatten sie losgelöst vom eigentlichen Kontext zu behandeln. Und das tue ich mit der Trennung von html und php. index.html bleibt index.html und cookie.php bleibt cookie.php.
      Klasse Tipp!

      Gruss nach Berlin
      AirMax