AndreR: Session Cookie deaktivieren

Ich möchte gerne erzwingen, dass eine Session komplett auf Server-Ebene abläuft. Ich arbeite an einem Browsergame und habe angst, der Eine oder die Andere könnte lokale Cookies manipulieren und auf diesem Wege cheaten. Ich habe an all meinen Links manuell ne SID angehängt, doch mit abgeschalteten Cookies geht meine Seite nicht, sobald man sich einloggen will.

Könnt Ihr mir bitte helfen?

  1. Servus,

    wodurch erhöht sich deiner Meinung nach die Sicherheit durch die Übermittlung der Session ID per URL-Parameter anstatt per Cookie?

    Gruss
    Patrick

    --
    sh:( fo:| ch:? rl:( br:> n4:( ie:% mo:) va:} de:> zu:) fl:| ss:| ls:[ js:|
    1. wodurch erhöht sich deiner Meinung nach die Sicherheit durch die Übermittlung der Session ID per URL-Parameter anstatt per Cookie?

      Wie ich das verstanden habe, liegt der Inhalt der Sesson-Variablen doch dann im Cookie und nicht auf dem Server. Genau das möhte ich unterbinden, dass die Variablen praktisch unter keinen Umständen vom Nutzer manipuliert werden können. Der soll nur die Verarbeiteten innerhalb der HTML-Datei bekommen - die Session soll komplett auf dem Server liegen.

      1. Servus,

        Wie ich das verstanden habe, liegt der Inhalt der Sesson-Variablen doch dann im Cookie und nicht auf dem Server.

        Dann hast du etwas falsch verstanden. Im Session-Cookie wird (per default) nur die Session-ID gespeichert. Die Daten werden auf dem Server gespeichert. Siehe dazu auch das Kapitel zu Sessions im PHP Manual.

        Gruss
        Patrick

        --
        sh:( fo:| ch:? rl:( br:> n4:( ie:% mo:) va:} de:> zu:) fl:| ss:| ls:[ js:|
        1. Dann hast du etwas falsch verstanden. Im Session-Cookie wird (per default) nur die Session-ID gespeichert. Die Daten werden auf dem Server gespeichert. Siehe dazu auch das Kapitel zu Sessions im PHP Manual.

          Wie mache ich es denn dann am besten, dass es am manipulationssichersten ist und dass der Nutzer keine Cookies braucht? Oder ist es mit Cookies sicherer als mit der SID in der URL? Auf jden Fall will ich eben das Cheaten unterbinden.

          1. Moin!

            Wie mache ich es denn dann am besten, dass es am manipulationssichersten ist und dass der Nutzer keine Cookies braucht? Oder ist es mit Cookies sicherer als mit der SID in der URL? Auf jden Fall will ich eben das Cheaten unterbinden.

            Definiere doch mal ein Beispiel von "cheaten". Dann können wir dir aufdröseln, warum das so extrem schwierig zu unterbinden ist - vollkommen unabhängig davon, ob du die Session-ID per URL oder per Cookie weiterreichst.

            - Sven Rautenberg

            --
            "Love your nation - respect the others."
            1. Definiere doch mal ein Beispiel von "cheaten". Dann können wir dir aufdröseln, warum das so extrem schwierig zu unterbinden ist - vollkommen unabhängig davon, ob du die Session-ID per URL oder per Cookie weiterreichst.

              Ihr müsst Euch das so vorstellen: Beim Login-Vorgang werden alle spielrelevanten Daten in die SID geschrieben, damit sie von überall ohne zusätzliche Zugriffe verfügbar sind. Sobald dann was geändert wird (und da bin ich mir nicht sicher, wie es am besten ist), werden die Daten dann entweder sofort in meinen Speicher zurückgeschrieben oder erst dann, wenn die Session abläuft, bzw. wenn man sich ausloggt. Letzteres hat auf den Fall einen Zugriffsbonus, da der Server entlastet wird, jedoch weiss ich nicht, ob ich die Daten zwanghaft beim beenden zurückschreiben kann, wenn der User z.B. einfach ohne Ausloggen die Seite zu macht.

              Ich will eben jetzt verhindern, dass der User die Daten irgendwie manipulieren kann, solange selbige auf seinem Rechner sind und daher am besten die kompletten Daten auf dem Server lassen, wo der User keinen Zugriff hat, dass der praktisch nur Formulare sehen kann, die dann vom Server auf Echtheit überprüft werden können.

              1. Hello,

                Ihr müsst Euch das so vorstellen: Beim Login-Vorgang werden alle spielrelevanten Daten in die SID geschrieben,

                Das kann ich mir aber nur schwer vorstellen, denn die Session ID (SID) ist nicht für Nutzdaten da, sondern eine Metainformation, ein Schlüssel für die Sessiondatei.

                Und die Sessiondatei liegt typischerweise auf dem Host, der die Requests bedient.
                Sie ist bei korrekter Einrichtung über HTTP nicht erreichbar und auch auf dem Server nur für den Virtual Host lesbar, dem sie gehört.

                Zweiteres ist leider bei vielen Providern noch nicht der Fall.
                Bei manchen kann man über shared Hosts noch die Sessiondateien der anderen User lesen oder sogar verändern. Man weiß davon aber nocb lange nicht, zu welcher Domain sie gehören.

                Harzliche Grüße vom Berg
                http://bergpost.annerschbarrich.de

                Tom

                --
                Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
                Nur selber lernen macht schlau
                Ein Jammer ist auch, dass die Dummen so selbstsicher und die Klugen voller Zweifel sind. Das sollte uns häufiger zweifeln lassen :-)

                1. Das kann ich mir aber nur schwer vorstellen, denn die Session ID (SID) ist nicht für Nutzdaten da, sondern eine Metainformation, ein Schlüssel für die Sessiondatei.

                  Ich ahbe einfach Session mit Session ID verwechselt ;).

                  Und die Sessiondatei liegt typischerweise auf dem Host, der die Requests bedient.
                  Sie ist bei korrekter Einrichtung über HTTP nicht erreichbar und auch auf dem Server nur für den Virtual Host lesbar, dem sie gehört.

                  Und das heist genau? Bisher habe ich die Session einfach erstellt und frage dann zu gegebener Zeit ab, ob die SID in der URL mit der auf dem Server übereinstimmt.

                  Zweiteres ist leider bei vielen Providern noch nicht der Fall.
                  Bei manchen kann man über shared Hosts noch die Sessiondateien der anderen User lesen oder sogar verändern. Man weiß davon aber nocb lange nicht, zu welcher Domain sie gehören.

                  Ich hoffe, ich habe dich nicht missverstanden: Das Game läuft auf dem Root von nem bekannten, der mir freundlicherweise für den Testlauf und für die Zeit der Programmierung Serverplatz zur verfügung stellt. Das ist also kein angemieteter Webspace, wenn Du das meintest.

                  1. Hello,

                    Und das heist genau? Bisher habe ich die Session einfach erstellt und frage dann zu gegebener Zeit ab, ob die SID in der URL mit der auf dem Server übereinstimmt.

                    Das musst Du gar nicht selber machen. Das macht das PHP-System für Dich schon ganz alleine.

                    Sven hat es doch in https://forum.selfhtml.org/?t=162274&m=1055971 schon recht ausführlich erklärt, wie der Mechanismus funktioniert.

                    Das Array $_SESSION wird für das jeweilige Script dann angelegt, wenn eine Session gestartet wurde. Vorher ist es nicht vorhanden. Wenn man es trotzdem benutzen würde (gemeint ist 'selber anlegen'), würde es beim Session-Start überschrieben werden.

                    Du musst also nur danach fragen "Ist das Session-Array da?" mit if(isset($_SESSION)) oder auch gleich danach fragen: Stehen die Variablen "User erkannt unter Nummer und angemeldet seit" zur Verfügung mit if( isset($_SERVER['usernummer'] and isset($_SESSION['logintime'])), dann kannst Du "hineinschauen" in die Variablen und feststellen, ob sie gültige Werte haben.

                    Wenn Du nun noch die aktuelle Session-ID und ggf. den letzten Requestzeitpunkt in der Datenbank ablegst, in der die Userdaten verwaltet werden, dann hast Du eine doppelte Kontrolle darüber, ob der User tatsächlich vorhanden _und_ angemeldet ist und kannst schnell überprüfen, wieviele User z.B. in den letzten fünf Minuten einen Request auf Deine Seiten durchgeführt haben und welche es sind.

                    Wenn die Sessiondatei zwar vorhanden ist und eine Session gestartet (ergo das Session-Array ist vorhanden), aber die notwendigen Variablen nicht da sind, dann ist die Session wahrscheinlich frisch und der Anmeldevorgang muss ggf. erst durchgeführt werden, wenn man das will. Dann kannst Du die Variablen anlegen und beim nächsten Request sollten sie automatisch (nach session_start() ) wieder zur Verfügung stehen.

                    Session hat aber grundsätzlich erstmal nichts mit "Anmelden" zu tun, sondern nur mit Wiedererkennen und Daten wieder zur Verfügung stellen.

                    Bei manchen kann man über shared Hosts noch die Sessiondateien der anderen User lesen oder sogar verändern. Man weiß davon aber nocb lange nicht, zu welcher Domain sie gehören.

                    Ich hoffe, ich habe dich nicht missverstanden: Das Game läuft auf dem Root von nem bekannten, der mir freundlicherweise für den Testlauf und für die Zeit der Programmierung Serverplatz zur verfügung stellt. Das ist also kein angemieteter Webspace, wenn Du das meintest.

                    Dann kannst Du erstens selber bestimmen (lassen), wer auf die Sessiondaten Zugriff haben könnte und außerdem besteht die Gefahr nicht, dass Euch Unbekannte Zugang zur Verwaltung des Servers oder Teilen davon haben.

                    Harzliche Grüße vom Berg
                    http://bergpost.annerschbarrich.de

                    Tom

                    --
                    Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
                    Nur selber lernen macht schlau
                    Ein Jammer ist auch, dass die Dummen so selbstsicher und die Klugen voller Zweifel sind. Das sollte uns häufiger zweifeln lassen :-)

                    1. Du musst also nur danach fragen "Ist das Session-Array da?" mit if(isset($_SESSION)) oder auch gleich danach fragen: Stehen die Variablen "User erkannt unter Nummer und angemeldet seit" zur Verfügung mit if( isset($_SERVER['usernummer'] and isset($_SESSION['logintime'])), dann kannst Du "hineinschauen" in die Variablen und feststellen, ob sie gültige Werte haben.

                      Ich habe jetzt wie beschrieben die isset-Abfrage gemacht. Aber dann bekomme ich permanent das Anmeldeformular angezeigt. Zwar wird gesagt, dass die Session erstellt wurde, doch etwas anderes auch nicht. Das Formular bleibt angezeigt.

                      1. Ich habe jetzt wie beschrieben die isset-Abfrage gemacht. Aber dann bekomme ich permanent das Anmeldeformular angezeigt. Zwar wird gesagt, dass die Session erstellt wurde, doch etwas anderes auch nicht. Das Formular bleibt angezeigt.

                        Das Problem konnte ich jetzt Lösen. Jedoch tut sich schon das nächste auf:

                        http://forum.de.selfhtml.org/my/?t=162372&m=1056587#m1056587

                        (Und sorry wegen Doppelpost, aber hier unten schaut wohl eh keiner mehr rein.)

                        1. Das Problem konnte ich jetzt Lösen. Jedoch tut sich schon das nächste auf:

                          http://forum.de.selfhtml.org/my/?t=162372&m=1056587#m1056587

                          Und auch Das konnte ich lösen. Und zwar damit:

                          if(isset($_COOKIE[session_name()])) {  
                            setcookie(session_name(), '', time()-42000, '/');  
                          }
                          

                          Trotzdem danke für eure zahlreiche Hilfe!

                        2. Moin!

                          Ich habe jetzt wie beschrieben die isset-Abfrage gemacht. Aber dann bekomme ich permanent das Anmeldeformular angezeigt. Zwar wird gesagt, dass die Session erstellt wurde, doch etwas anderes auch nicht. Das Formular bleibt angezeigt.

                          Das Problem konnte ich jetzt Lösen. Jedoch tut sich schon das nächste auf:

                          http://forum.de.selfhtml.org/my/?t=162372&m=1056587#m1056587

                          Es bringt relativ wenig, wenn du auf dein Doppelposting verweist, welches nicht archiviert wird. Davon hat am Ende niemand was.

                          Also kopiere ich deine Problembeschreibung mal (wäre eigentlich deine Aufgabe):

                          Ich bin jetzt soweit durch und habe die Sache mit isset($_COOKIE['PHPSESSID']) realisiert, da es mit isset($_SESSION) nicht funktionieren wollte. Auf diese Weise geht es jetzt auf jdenen Fall.

                          Jetzt stellt sich die Frage, wie ich die Session beenden kann. Ich habe z.Z. folgenden Code:
                          <?php
                            session_start();
                            session_unset();
                            session_destroy();
                            header("Location: ../index.php?show=logout");
                          ?>
                          Leider funktioniert der Code nicht so, wie er sollte, denn der Session-Cookie wird nicht gelöscht, was zu Problemen in meinem Script führt. Kann ich diesen manuell löschen bzw. gibt es eine andere Lösung? Ich habe schon "setcookie("PHPSESSID", "", time()-3600);", was allerdings nicht sonderlich erfolgreich war.

                          Deine Herangehensweise ist bislang: Wenn jemand eingeloggt ist, dann gibts eine Session - wenn nicht, dann nicht.

                          Das ist grundsätzlich falsch. Es gibt immer eine Session - davon solltest du ausgehen. Aber eine Session kann den Zustand "eingeloggt" haben, oder den Zustand "ausgeloggt". Das speicherst du in einer entsprechenden Session-Variable. Wenn die Variable nicht existiert, ist die Session ausgeloggt, wenn die Variable existiert und einen sinnvollen Inhalt hat (z.B. den authentifizierten Usernamen, oder einfach $_SESSION['eingeloggt'] = true), dann ist man eingeloggt.

                          Dann brauchst du auch nicht irgendwelche Verrenkungen mit a) der Existenz von Cookieparametern und b) von Sessiondaten machen.

                          (Und sorry wegen Doppelpost, aber hier unten schaut wohl eh keiner mehr rein.)

                          Alle, die in diesem Forum fachlich helfen können, scannen üblicherweise das gesamte Forum. Und insbesondere diejenigen, die sich an einem Thread schon beteiligt haben, haben den eigentlich immer im Blick, weil sie bereits gelesene Postings markieren lassen und so neue Postings direkt erkennen.

                          - Sven Rautenberg

                          --
                          "Love your nation - respect the others."
              2. Moin!

                Ihr müsst Euch das so vorstellen: Beim Login-Vorgang werden alle spielrelevanten Daten in die SID geschrieben, damit sie von überall ohne zusätzliche Zugriffe verfügbar sind.

                Deine Formulierung ist sachlich/fachlich nicht ganz korrekt. Die exakte Formulierung ist:
                "Beim Login werden alle relevanten Daten in das Array $_SESSION geschrieben, damit sie von überall ohne zusätzliche Zugriffe verfügbar sind."

                Und jetzt für dich die Info, wie die Sessions von PHP arbeiten:
                1. Ein Request kommt rein. Der Request liefert eine Session-ID mit, und zwar entweder als Cookie, oder ohne Cookie in der URL (oder in Formular-POST-Daten, wenn's kein GET-Request ist).
                2. Sobald PHP den Befehl session_start() ausführt, wird eine Datei im Sessiondaten-Verzeichnis geöffnet und für parallele Lesezugriffe gesperrt, deren Namen mit der Session-ID übereinstimmt. In dieser Datei ist der Inhalt des Arrays $_SESSION serialisiert gespeichert. Die Datei wird ausgelesen, das Array $_SESSION wird mit dem Dateiinhalt wieder befüllt, und PHP arbeitet den nächsten Befehl ab.
                3. Das Skript kann ab jetzt auf $_SESSION zugreifen, lesen und ändern.
                4. Am Skriptende, oder bei Erreichen des Befehls session_write_close(), wird der aktuelle Inhalt des Arrays $_SESSION wieder in die noch geöffnete Datei geschrieben und diese geschlossen und dadurch freigegeben.

                Zu keiner Zeit verlassen die Daten in $_SESSION den Server in Richtung Client - außer du selbst schickst diese Inhalte dorthin.

                Außerdem sorgt das Locking der Session-Datei dafür, dass sie Anzahl parallel ablaufender Skriptaufrufe einer Session faktisch auf 1 reduziert ist - nur falls geplant ist, dass z.B. irgendwelche Framesets oder Bildauslieferungsskripte auch auf die Session zugreifen...

                Letzteres hat auf den Fall einen Zugriffsbonus, da der Server entlastet wird, jedoch weiss ich nicht, ob ich die Daten zwanghaft beim beenden zurückschreiben kann, wenn der User z.B. einfach ohne Ausloggen die Seite zu macht.

                Du machst, noch ohne dass du überhaupt den realen Fall hast eintreten lassen, Annahmen über scheinbare Performanceprobleme, die sich möglicherweise als vollkommen unbegründet oder möglicherweise auch total falsch herausstellen könnten.

                Die übliche Parole lautet: Du kannst nur etwas optimieren, was du auch messen kannst. Solange du nichts mißt, solltest du dir über Optimierungen nicht den Kopf zerbrechen.

                Ich will eben jetzt verhindern, dass der User die Daten irgendwie manipulieren kann, solange selbige auf seinem Rechner sind und daher am besten die kompletten Daten auf dem Server lassen, wo der User keinen Zugriff hat, dass der praktisch nur Formulare sehen kann, die dann vom Server auf Echtheit überprüft werden können.

                Genau das passiert, wenn du einfach ohne Extra-Aufwand PHP-Sessions benutzt.

                - Sven Rautenberg

                --
                "Love your nation - respect the others."
                1. Genau das passiert, wenn du einfach ohne Extra-Aufwand PHP-Sessions benutzt.

                  Also kann ich mir dann praktisch die SID in der URL sparen, da selbige über den Weg des Cookies ebenfalls ankommt?

                  1. Moin!

                    Genau das passiert, wenn du einfach ohne Extra-Aufwand PHP-Sessions benutzt.

                    Also kann ich mir dann praktisch die SID in der URL sparen, da selbige über den Weg des Cookies ebenfalls ankommt?

                    Du hast es erfaßt. PHP wird die SID automatisch in die URL packen, wenn es so konfiguriert ist, falls Cookies nicht akzeptiert werden - man kann dieses Verhalten allerdings konfigurieren, d.h. wenn man dieses Verhalten nicht will, ließe es sich abschalten, und umgekehrt (je nachdem, wie der Provider das voreingestellt hat).

                    - Sven Rautenberg

                    --
                    "Love your nation - respect the others."
                    1. Du hast es erfaßt. PHP wird die SID automatisch in die URL packen, wenn es so konfiguriert ist, falls Cookies nicht akzeptiert werden - man kann dieses Verhalten allerdings konfigurieren, d.h. wenn man dieses Verhalten nicht will, ließe es sich abschalten, und umgekehrt (je nachdem, wie der Provider das voreingestellt hat).

                      Nun ja, ich habe es glaube ich schon recht weit oben geschrieben: Wenn ich Cookies nicht akzeptiere, funktioniert das Login nicht mehr - man wird sofort wider ausgeloggt. Wie kann man das denn einstellen?

                      1. Hello,

                        Nun ja, ich habe es glaube ich schon recht weit oben geschrieben: Wenn ich Cookies nicht akzeptiere, funktioniert das Login nicht mehr - man wird sofort wider ausgeloggt. Wie kann man das denn einstellen?

                        Du könntest dann entweder die session.trans_sid benutzen (session.use_only_cookies muss dazu off sein) oder du wechselst dann gleich zu Basic Auth mit Status 401. Dann klappt aber das unbeliebte Anmeldefenster am Client auf und "abmelden" geht auch nicht wirklich.

                        Harzliche Grüße vom Berg
                        http://bergpost.annerschbarrich.de

                        Tom

                        --
                        Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
                        Nur selber lernen macht schlau
                        Ein Jammer ist auch, dass die Dummen so selbstsicher und die Klugen voller Zweifel sind. Das sollte uns häufiger zweifeln lassen :-)

                        1. Du könntest dann entweder die session.trans_sid benutzen (session.use_only_cookies muss dazu off sein) oder du wechselst dann gleich zu Basic Auth mit Status 401. Dann klappt aber das unbeliebte Anmeldefenster am Client auf und "abmelden" geht auch nicht wirklich.

                          Und wie stellt man das ein? Gibt es da ne Funktion dazu? Muss ich dann etwas anderes abschalten (da gibts glaube ich zwei verschiedene Einstellungsparameter, oder)?

                          1. Hello,

                            Du könntest dann entweder die session.trans_sid benutzen (session.use_only_cookies muss dazu off sein) oder du wechselst dann gleich zu Basic Auth mit Status 401. Dann klappt aber das unbeliebte Anmeldefenster am Client auf und "abmelden" geht auch nicht wirklich.

                            Und wie stellt man das ein? Gibt es da ne Funktion dazu? Muss ich dann etwas anderes abschalten (da gibts glaube ich zwei verschiedene Einstellungsparameter, oder)?

                            In einer Virtual Host Umgebung würde ich es auf jeden Fall in der Konfiguration des Virtual Host einstellen. Ob da nun eine (lokale) php.ini angepasst werden muss oder ob man es in die Hostdirektiven für die Directories mit aufnimmt, das hängt davon ab, ob PHP als Modul oder als CGI ausgeführt wird.

                            Die Einstellparameter findest Du im Handbuch unter
                            http://de3.php.net/manual/de/ini.php#ini.list

                            Harzliche Grüße vom Berg
                            http://bergpost.annerschbarrich.de

                            Tom

                            --
                            Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
                            Nur selber lernen macht schlau
                            Ein Jammer ist auch, dass die Dummen so selbstsicher und die Klugen voller Zweifel sind. Das sollte uns häufiger zweifeln lassen :-)

                            1. Wie könnte ich denn alternativ dazu die SID aus dem Cookie bekommen, um zu schauen, ob diese mit der auf dem Server übereinstimmt. Bisher mache ich das mit if($_GET['SID'] == session_id()). Gibt es sowas auch für Cookies?

                              1. Moin!

                                Wie könnte ich denn alternativ dazu die SID aus dem Cookie bekommen, um zu schauen, ob diese mit der auf dem Server übereinstimmt. Bisher mache ich das mit if($_GET['SID'] == session_id()). Gibt es sowas auch für Cookies?

                                Es gibt "auf dem Server" keine Session-ID, die du mit der des Clients vergleichen könntest. Jedenfalls nicht sinnvoll. Denn der Server nimmt exakt die Session-ID, die der Client ihm liefert. Denn das ist das eindeutige Identifikationsmerkmal, an dem ein Client wiedererkannt wird.

                                Dein Vergleich ist, je nachdem, wo er im Code vorkommt, also entweder sinnlos, oder wird scheitern.

                                Der Parameter im Cookie oder in der URL heißt übrigens so, wie die Funktion session_name() dir sagt.

                                - Sven Rautenberg

                                --
                                "Love your nation - respect the others."
                                1. Es gibt "auf dem Server" keine Session-ID, die du mit der des Clients vergleichen könntest. Jedenfalls nicht sinnvoll. Denn der Server nimmt exakt die Session-ID, die der Client ihm liefert. Denn das ist das eindeutige Identifikationsmerkmal, an dem ein Client wiedererkannt wird.

                                  Und wie verhindert man dann manipulation durch gefälschte, erratene oder was auch immer SIDs?

                                  1. Moin!

                                    Es gibt "auf dem Server" keine Session-ID, die du mit der des Clients vergleichen könntest. Jedenfalls nicht sinnvoll. Denn der Server nimmt exakt die Session-ID, die der Client ihm liefert. Denn das ist das eindeutige Identifikationsmerkmal, an dem ein Client wiedererkannt wird.

                                    Und wie verhindert man dann manipulation durch gefälschte, erratene oder was auch immer SIDs?

                                    Das kann man nicht verhindern. Allerdings ist der Wertebereich denkbarer SIDs so riesig groß, dass mit Raten keine Möglichkeit zum Erfolg besteht.

                                    Lediglich wenn man Kommunikation belauschen kann, sieht man die SID. Dann muß man aber nicht raten - und dann hat man natürlich noch ganz Möglichkeiten.

                                    - Sven Rautenberg

                                    --
                                    "Love your nation - respect the others."
  2. Grüße,
    user hat (egal ob als SID in URL oder in cookies) nur eine ID der SESSIONdatei auf dem server, mit diesem ID kann der server dem user seine session zuweisen, diese ist aber nur vom server lesbar.
    MFG
    bleicher

    --
    __________________________-
    Menschen an sich , sind nicht schlecht - es sind nur ihre Taten (c).
    Lieber bereuen gesündigt zu haben, als nicht sündigen und es später trotzdem bereuen.
    Boccaccio