joehosch: make_dir() Funktion gesucht (loginsystem)

Hallo,

Im Beitrag http://wiki.selfhtml.org/wiki/PHP/Anwendung_und_Praxis/Loginsystem

verwendet der Autor eine Funktion, die aber nicht referenziert ist und eine Fehlermeldung ausgibt:

Fatal error: Call to undefined function make_dir() in C:\xampp\htdocs\termine\auth_config.php on line 94

ich habe es durch mkdir ersetzt, das gab andere Probleme, aber es entstand (irgendwie) ein Verzeichnis sessions und das Problem trat nicht mehr auf. Allerdings in meinem xampp-System auf Win7. Natürlich werde ich dann auf dem Server vorher ein entspr. Verzeichnis einrichten, aber trotzdem:

_Was ist das für eine Funktion, wo ist sie beschrieben, bzw. wodurch kann man sie ersetzen? _ Horst

  1. Hallo joehosch,

    Im Beitrag http://wiki.selfhtml.org/wiki/PHP/Anwendung_und_Praxis/Loginsystem

    verwendet der Autor eine Funktion, die aber nicht referenziert ist und eine Fehlermeldung ausgibt:

    Fatal error: Call to undefined function make_dir() in C:\xampp\htdocs\termine\auth_config.php on line 94

    Ich gehe davon aus, dass die Funktion rekursiv das Verzeichnis erstellen soll, also etwa bei /tmp/app/sessions dann den app/sessions-Teil. Das kann auch mkdir erledigen, mit den richtigen Flags:

    mkdir('/tmp/app/sessions', 0777, true)
    

    Das dritte Flag weist mkdir an, den Baum rekursiv zu erstellen soweit nötig.

    LG,
    CK

    1. Tach!

      mkdir('/tmp/app/sessions', 0777, true)
      

      Wenn das Script das Verzeichnis nur für sich selbst braucht, dann ist es besser, 0700 als Berechtigung zu nehmen, statt weltweiten Zugriff zu gestatten.

      dedlfix.

      1. Hallo dedlfix,

        mkdir('/tmp/app/sessions', 0777, true)
        

        Wenn das Script das Verzeichnis nur für sich selbst braucht, dann ist es besser, 0700 als Berechtigung zu nehmen, statt weltweiten Zugriff zu gestatten.

        Dafür sorgt die umask.

        LG,
        CK

        1. Tach!

          Wenn das Script das Verzeichnis nur für sich selbst braucht, dann ist es besser, 0700 als Berechtigung zu nehmen, statt weltweiten Zugriff zu gestatten.

          Dafür sorgt die umask.

          Warum implizit und nicht explizit? Es ist besser, an Ort und Stelle zu sehen was passiert und nicht das ganze Script durchsuchen zu müssen, ob irgendwo anders die sicherheitsrelevanten Maßnahmen versteckt sind.

          dedlfix.

          1. Hallo dedlfix,

            Wenn das Script das Verzeichnis nur für sich selbst braucht, dann ist es besser, 0700 als Berechtigung zu nehmen, statt weltweiten Zugriff zu gestatten.

            Dafür sorgt die umask.

            Warum implizit und nicht explizit? Es ist besser, an Ort und Stelle zu sehen was passiert und nicht das ganze Script durchsuchen zu müssen, ob irgendwo anders die sicherheitsrelevanten Maßnahmen versteckt sind.

            Weil die umask ein bekanntes und bewährtes Konzept ist. Und weil sie auf jeden Fall wirkt, egal, ob du das toll findest oder nicht, man müsste sie vorher explizit auf 000 setzen, falls man das Feature „abschalten“ will ;-)

            LG,
            CK

            1. Tach!

              Weil die umask ein bekanntes und bewährtes Konzept ist. Und weil sie auf jeden Fall wirkt, [...]

              Es ist ja durchaus sinnvoll eine umask zu haben - zumindest für die Stellen, an denen man keine Rechte angibt (ob das wiederum sinvoll ist, sei mal dahingestellt) - aber deren Verwendung setzt nicht zwingend voraus, den 0777er Holzhammer rauszuholen.

              Aus der 0777 geht nicht hervor, ob du bewussst auf die umask setzt oder eigentlich doch weltweites Schreibrecht haben wolltest. Wenn du dem Leser mitteilen möchtest, was du wirklich willst, müsstest du einen Kommentar dazuschreiben. Und das ist deutlich aufwendiger als gleich 0700 zu notieren.

              Im Zweifelsfall kopiert man auch nur den Teil ohne umask. Und genau das ist ja in deiner Antwort bereits geschehen und hat zumindest eine Diskussion angezettelt.

              dedlfix.

              1. Hallo dedlfix,

                Weil die umask ein bekanntes und bewährtes Konzept ist. Und weil sie auf jeden Fall wirkt, [...]

                Es ist ja durchaus sinnvoll eine umask zu haben - zumindest für die Stellen, an denen man keine Rechte angibt (ob das wiederum sinvoll ist, sei mal dahingestellt) - aber deren Verwendung setzt nicht zwingend voraus, den 0777er Holzhammer rauszuholen.

                Das tue ich ja nicht. Ich gehe davon aus, dass eine umask gesetzt ist - und das ist der Default-Fall (genauer gesagt, 022). Ich komme um die umask also nur herum, wenn ich sie vorher absichtlich anders setze. Und wer das tut, weiss idR, was er tut.

                Aus der 0777 geht nicht hervor, ob du bewusst auf die umask setzt oder eigentlich doch weltweites Schreibrecht haben wolltest. Wenn du dem Leser mitteilen möchtest, was du wirklich willst, müsstest du einen Kommentar dazuschreiben. Und das ist deutlich aufwendiger als gleich 0700 zu notieren.

                Wenn ich 0700 notiere, dann ist das aber nicht mehr mit den Rechten des System-Defaults. Und konsistente Rechte, die den System-Defaults entsprechen, schätze ich deutlich höher.

                Im Zweifelsfall kopiert man auch nur den Teil ohne umask.

                Perfekt, dann haben wir den Default-Fall, also genau das, was ich wollte.

                LG,
                CK

                1. Tach!

                  Das tue ich ja nicht. Ich gehe davon aus, dass eine umask gesetzt ist - und das ist der Default-Fall (genauer gesagt, 022). Ich komme um die umask also nur herum, wenn ich sie vorher absichtlich anders setze. Und wer das tut, weiss idR, was er tut.

                  Dann bleibt noch die Frage, warum das Verzeichnis für Gruppe und andere lesbar sein muss.

                  Wenn ich 0700 notiere, dann ist das aber nicht mehr mit den Rechten des System-Defaults. Und konsistente Rechte, die den System-Defaults entsprechen, schätze ich deutlich höher.

                  Ich schätze es deutlich höher, nur genau die benötigten Rechte zu vergeben.

                  dedlfix.

                  1. Moin!

                    Tach!

                    Das tue ich ja nicht. Ich gehe davon aus, dass eine umask gesetzt ist - und das ist der Default-Fall (genauer gesagt, 022). Ich komme um die umask also nur herum, wenn ich sie vorher absichtlich anders setze. Und wer das tut, weiss idR, was er tut.

                    Dann bleibt noch die Frage, warum das Verzeichnis für Gruppe und andere lesbar sein muss.

                    Weil Verzeichnislesbarkeit für die Welt in einem Webserver-Umfeld durchaus normal ist?

                    Zu dem zugewiesene User- und Gruppen-Account hast du noch gar nichts gesagt. Das ist auch "default".

                    Und in der Doku zu mkdir() steht:

                    Beachten Sie, dass Sie den Modus als oktalen Wert angeben sollten, d.h., dass er eine führende Null haben sollte. Der Modus wird auch durch die aktuelle umask geändert, die Sie mit umask() ändern können.

                    0777 ist für den zweiten Parameter von mkdir() übrigens Standard - und es entspricht der üblichen Vorgehensweise in PHP, in den Fällen, wo man die vorderen Parameter nicht mit abweichenden Werten belegen will, sondern den Defaultwert will, aber an die hinteren Parameter ran muss, den Defaultwert explizit anzugeben.

                    Anders geht es nicht!

                    Wenn ich 0700 notiere, dann ist das aber nicht mehr mit den Rechten des System-Defaults. Und konsistente Rechte, die den System-Defaults entsprechen, schätze ich deutlich höher.

                    Ich schätze es deutlich höher, nur genau die benötigten Rechte zu vergeben.

                    Welche Rechte sind das? Und wieso willst du dich darauf verlassen, dass die benötigten Rechte in allen Skripten korrekt explizit gesetzt wurden? Das ist eigentlich Admin-Aufgabe, es zu definieren, und OS-Aufgabe, es zu forcieren.

                    Grüße Sven

                    1. Tach!

                      Dann bleibt noch die Frage, warum das Verzeichnis für Gruppe und andere lesbar sein muss.

                      Weil Verzeichnislesbarkeit für die Welt in einem Webserver-Umfeld durchaus normal ist?

                      Gut, alles klar, dann werd ich mich mal umstellen und die anwendungsspezifischen Daten inklusive der sensiblen nicht nur anwendungsspezifisch sondern weltweit lesbar berechtigen. Wenn das so üblich ist, dann wird das wohl so richtig sein.

                      Zu dem zugewiesene User- und Gruppen-Account hast du noch gar nichts gesagt. Das ist auch "default".

                      Das ist der, unter dem die Anwendung läuft. Bestenfalls ist das ein separater Account. Jedenfalls ist das auch der Account, der die Daten wieder lesen muss. Ich weiß zwar nicht, welche anderen Accounts die Daten noch lesen können müssen, aber wenn das so üblich ist ...

                      0777 ist für den zweiten Parameter von mkdir() übrigens Standard - und es entspricht der üblichen Vorgehensweise in PHP, in den Fällen, wo man die vorderen Parameter nicht mit abweichenden Werten belegen will, sondern den Defaultwert will, aber an die hinteren Parameter ran muss, den Defaultwert explizit anzugeben.

                      Im vorliegenden Fall wurde nach dem Erstellen des Verzeichnisses mit chmod() cie Berechtigung auf 0700 gesetzt. Das ist natürlich falsch, weil es kein Standard ist, deswegen wurde es ja in Christians Alternative zu der verwendeten Funktion auf 0777 gesetzt. Die auf 0077 gesetzte umask in Jörgs Code ist somit wohl auch falsch, weil kein Standard. (Die Hinweise im PHP-Handbuch, dass das Setzen der Umask unter bestimmten Serverkonfigurationen ungewünschte Nebenwirkungen hat, weil das auf mehr als den aktuellen Prozess wirkt, kann man sicher auch vernachlässigen. 0777 als Recht und die Default-Umask - wie auch immer sie grad von irgendwem anders umgebogen wurde - werden schon alle so richten, wie es der Standard braucht.)

                      Ich schätze es deutlich höher, nur genau die benötigten Rechte zu vergeben.

                      Welche Rechte sind das?

                      So wie es die Anwendung braucht. Lesen und Schreiben für sie selbst und andere Accounts brauchen nichts. Jedenfalls geht aus dem im OP (nicht) verlinkten Artikel nicht hervor, dass das sessionbasierte Loginsystem ein anwendungsübergeifendes sein soll.

                      Und wieso willst du dich darauf verlassen, dass die benötigten Rechte in allen Skripten korrekt explizit gesetzt wurden?

                      Ich verlasse mich darauf, dass ich solchen zentralen Code nicht mehrfach kopiere sondern er nur in einer Datei (oder einen Modul oder wie auch immer das Pojekt gegliedert ist) steht, die bei Bedarf von den anderen referenziert wird.

                      Das ist eigentlich Admin-Aufgabe, es zu definieren, und OS-Aufgabe, es zu forcieren.

                      Und ich als kleiner Anwendungsprogrammierer darf mich um die Sicherheit nicht selbst kümmern? Wahrscheinlich nicht, weil es kein Standard ist. Das bestätigen ja auch die vielen Meldungen in den heise News über Sicherheitslücken in den Anwendungen. Man sollte denen mal sagen, dass Sicherheitslücken nicht entstehen zu lassen, reine Administratoren-Aufgabe ist.

                      Vielleicht hab ich auch wieder nur grad alles falsch verstanden ( - wie neulich bei den RewriteRules vom Zend Framework. Nur leider hat es mir keiner erklären können.)

                      dedlfix.

                      1. Moin!

                        Im vorliegenden Fall wurde nach dem Erstellen des Verzeichnisses mit chmod() cie Berechtigung auf 0700 gesetzt. Das ist natürlich falsch, weil es kein Standard ist

                        Moment mal, das geht mir jetzt nicht ein.

                        Ich unterscheide zwei Fälle:

                        a) Eigener Server (Blech oder virtuell):

                        Der Webserver läuft mit den Rechten eines speziellen Benutzers (www-run || www-data). Der Webserver legt den Ordner an und in dem sollen die Session-dateien abgelegt werden. Ich sehe offen gestanden keinen Grund, warum ein anderer Benutzer - bestenfalls könnte ich mir vorstellen noch die Gruppe (www-run || www-data) - mit einzubeziehen, an dem Verzeichnis Rechte haben soll. Das damit nicht der root ran muss, wenn da mal manuell eingeriffen werden soll (z.B. um durch das Löschen der Dateien alle Sessions zu Canceln) Hab so schon genug Bauchschmerzen, weil irgend ein Joomla oder Wordpress-Plugin den lesenden Zugriff auf das Session-Verzeichnis ermöglichen könnte.

                        b) Shared Hosting mit suhosin (was wohl der Standard ist)

                        Da hab ich keine Bauchschmerzen mehr sondern bin schon tot, wenn ich anderen Kunden (also Usern) ermögliche, womöglich fremde Session-Dateien zu listen. Die könnten dann nämlich die Session ebenso leicht hacken wie wenn diese in der URI mitgeführt wird.

                        Chmod 0700 für das Verzeichnis scheint mir insofern ideal. Wenn aber der die unter A) aufgeführte Möglichkeit (0770) eine breite Zustimmung findet, dann nehme ich die Wahl zwischen 0700 und 0770 als Möglichkeit gerne in die Konfiguration auf. Aber 0777 oder auch nur 0775 bzw. 0755 (≈umask 022) geht aus meiner Sicht ganz und überhaupt nicht und es braucht diese auch nicht.

                        Insofern lasse ich es erst mal bei:

                        $dummy=umask(0077);
                        if (! mkdir(SESSION_FILE_DIR . '/', 0700, true) ) {
                        

                        ** und warte die Diskussion ab. Änderungsvorschlag wäre: (Achtung: blind geschrieben, Voraussichtlich sind Typos enthalten!)**

                        ##Konfiguration:
                        ## Wenn Sie einen eigenen Server haben (kein Shared Hosting!) kann es sinnvoll sein
                        ## diesen Wert auf false zu setzen, dann kann jeder Benutzer mit den Rechten der Gruppe
                        ## des Webservers (oft: www-data) die Session-Dateien ansehen und z.B. löschen:
                        define('SHARED_HOSTING', true);## Programm
                        
                        if (SHARED_HOSTING) {
                           define(SELF_AUTH_UMASK, 0077);
                           define(SELF_AUTH_DIR_MOD, 0700);
                           define(SELF_AUTH_FILE_MOD, 0600); # Auf Vorrat für die künftige Benutzung :)
                        } else {
                           define(SELF_AUTH_UMASK, 0007);
                           define(SELF_AUTH_DIR_MOD, 0770);
                           define(SELF_AUTH_FILE_MOD, 0660); # Auf Vorrat für die künftige Benutzung :)
                        }$dummy=umask(SELF_AUTH_UMASK); # Vorgezogen, weil es irgendwie unlogisch ist, die umask zu setzen oder nicht.
                        if ( defined('SESSION_FILE_DIR') ) {
                            if (! is_dir( SESSION_FILE_DIR ) ) {
                               if (! mkdir(SESSION_FILE_DIR . '/', SELF_AUTH_DIR_MOD, true) ) {
                                 trigger_error('Fatal: Unmöglich, das Verzeichnis für die Session-Dateien anzulegen.', E_USER_ERROR);
                               }
                               if (! chmod( SESSION_FILE_DIR, SELF_AUTH_DIR_MOD ) ) {
                        	  trigger_error('Fatal: Unmöglich, die Rechte für das Verzeichnis mit Session-Dateien zu setzen.', E_USER_ERROR);
                               }
                               if (! file_put_contents(SESSION_FILE_DIR . '/' . '.htaccess', 'deny from all') ) {
                                  trigger_error('Fatal: Unmöglich, das Verzeichnis für die Session-Dateien zu sperren.', E_USER_ERROR);
                               }  
                        #### Option zur Diskussion ####
                               if (! chmod( SESSION_FILE_DIR . '/' . '.htaccess', 0000) ) {
                                  trigger_error('Fatal: Unmöglich, die Datei ' . SESSION_FILE_DIR . '/' . '.htaccess' . ' zu sperren', E_USER_ERROR);
                               }  
                            }
                            if (! is_writable(SESSION_FILE_DIR) ) {
                              trigger_error('Fatal: Es ist unmöglich, die Session-Dateien anzulegen.', E_USER_ERROR);
                            }
                        }
                        

                        Jörg Reinholz

                        1. Tach!

                          Im vorliegenden Fall wurde nach dem Erstellen des Verzeichnisses mit chmod() cie Berechtigung auf 0700 gesetzt. Das ist natürlich falsch, weil es kein Standard ist

                          Moment mal, das geht mir jetzt nicht ein.

                          Mir auch nicht, das war auch von mir sarkastisch/ironisch/sowas gemeint.

                          Ich unterscheide zwei Fälle:
                          a) Eigener Server (Blech oder virtuell):
                          Der Webserver läuft mit den Rechten eines speziellen Benutzers (www-run || www-data).

                          Das mach ich selbst bei Servern nicht, die nur eine Anwendung beherbergen sollen. Ich vergebe auch dieser Anwendung einen eigenen Account. Da kommt später garantiert noch was daneben, und sei es ein phpMyAdmin. Das soll und muss nicht alles unter einem Account laufen. Dieses Vorgehen bedingt allerdings auch, dass PHP nicht als Modul sondern als FCGI eingebunden ist, damit SuexecUserGroup funktionieren kann.

                          Der Webserver legt den Ordner an und in dem sollen die Session-dateien abgelegt werden. Ich sehe offen gestanden keinen Grund, warum ein anderer Benutzer - bestenfalls könnte ich mir vorstellen noch die Gruppe (www-run || www-data) - mit einzubeziehen, an dem Verzeichnis Rechte haben soll.

                          Ich auch nicht, deswegen vergebe ich da explizit 0700. Die Argumentation von Christian war nun aber, dass das nicht Aufgabe des Scripts sein, sondern die des Administrator, das System so einzurichten, dass sich nichts in die Quere kommt. Und er ließ auch nicht gelten, dass nicht jeder einen Administrator hat, der das Ding sicher aufsetzt - so hab ich ihn verstanden.

                          Nun ist aber der vorliegende Wiki-Artikel nicht nur für den administrativ sicheren Fall gedacht. Und da sehe ich es als nicht verkehrt an, die Rechte mit 0700 bestmöglich sicher zu setzen.

                          $dummy=umask(0077);

                          Die Frage ist dann noch, ob das Setzen der Umask eine gute Idee ist. Das wirkt nämlich nicht nur für das aktuelle Script sondern in multithreaded Webservern auf noch viel mehr. Und dann ergibt sich für mich die Frage, ob das Sichverlassen auf die Umask eine gute Idee ist. Oder kann mir jemand die Bedenken zerstreuen, dass einem da keine ungewollte Umask untergeschoben wird?

                          dedlfix.

                          1. Moin!

                            Und dann ergibt sich für mich die Frage, ob das Sichverlassen auf die Umask eine gute Idee ist.

                            Das ist es dann nicht, wenn ich speziell includierten Libs nicht vertrauen kann. Ich sag nur Joomla, Wordpress, Templates und von diesen mitgelieferte Plugins. Im Web stehen ganze Rechenzentren voller Server, die "irgendwie ein wenig mehr" machen als deren Mieter sich das so vorgestellt haben.

                            Jörg Reinholz

                        2. Moin!

                          und warte die Diskussion ab. Änderungsvorschlag wäre:

                          1 von 1 Teilnehmern hat wohl gemeint, ich soll das machen.

                          [x] eingepflegt.

                          Jörg Reinholz

  2. Hallo

    Im Beitrag PHP/Anwendung und Praxis/Loginsystem verwendet der Autor eine Funktion, die aber nicht referenziert ist und eine Fehlermeldung ausgibt:

    Fatal error: Call to undefined function make_dir() in C:\xampp\htdocs\termine\auth_config.php on line 94

    Dann fragen wir doch einfach mal den Autoren, der sich hier regelmäßg herumtreibt. Ich hoffe, dass ihm der geänderte Betreff auffällt und bilde mir zudem ein, dass er hier schon irgendwas dazu geschrieben hat.

    Tschö, Auge

    --
    Verschiedene Glocken läuteten in der Stadt, und jede von ihnen vertrat eine ganz persönliche Meinung darüber, wann es Mitternacht war. Terry Pratchett, “Wachen! Wachen!
    1. Moin!

      Wozu steht eigentlich meine Mail-Adresse im Artikel. Man kann mich direkt fragen ohne hier herumzuschreien.

      Zur Sache:

      Ja. Mein Fehler! Ich habe make_dir() durch mkdir() ersetzt. Konkret:

      mkdir(SESSION_FILE_DIR . '/', true);
      
      

      Stratoalarm

      Ich musste leider zur Kenntnis nehmen, dass die Skripte auf Servern von Strato nicht funktionieren. Hintergrund ist eine recht außergewöhnliche Konfiguration bei Strato. Dort wohl intensiv mit Links gearbeitet.

      während DIR etwas ausgibt, wie

      /foo/bar/baz
      

      steht $_SERVER['DOCUMENT_ROOT'] auf Grund der Links und Konfiguration auf

      auf etwas wie:

      /gjgj/rtrt/tttrtr/foo/baz
      

      Ich habe zwar schon im Einzelfall eine Lösung geboten (manuelle Anpassung der Skripte) aber das ist nicht so recht befriedigend.

      Jörg Reinholz

      1. Moin!

        während DIR etwas ausgibt, wie

        Verflixt: das sollte ein DIR mit je zwei Unterstrichen davor und danach werden. Wie gibt man die hier ein?

        __DIR__ ? Alles klar: \_\_DIR\_\_

        Jörg Reinholz

        1. Hallo Jörg,

          während DIR etwas ausgibt, wie

          Verflixt: das sollte ein DIR mit je zwei Unterstrichen davor und danach werden. Wie gibt man die hier ein?

          __DIR__ ? Alles klar: \_\_DIR\_\_

          Die richtige Auszeichnung wäre hier __DIR__, weil es ja Code ist ;-)

          LG,
          CK

      2. Tach!

        Wozu steht eigentlich meine Mail-Adresse im Artikel. Man kann mich direkt fragen ohne hier herumzuschreien.

        Außerdem hat das Forum ein Post-System, mit dem man ebenfalls jemanden informieren kann.

        dedlfix.

      3. Hallo

        Wozu steht eigentlich meine Mail-Adresse im Artikel. Man kann mich direkt fragen ohne hier herumzuschreien.

        Sorry, ich wollte dir keineswegs auf die Füße treten. An die verbesserten und erweiterten Möglichkeiten der Kontaktaufnahme hier muss ich mich erstmal gewöhnen. Bisher haben wir halt einfach gebläkt [1], das muss ich mir erst regelrecht abgewöhnen [2].

        • [1] Ich brauche Urlaub.
        • [2] Raus aus dem steinzeitlichen Benehmen!

        Tschö, Auge

        PS: Dass hier allerlei Mumpitz als Tags angeboten wird, ist ja ganz witzig und bietet Spielraum. Dass seit heute eindeutige Tags angelegt und nicht mehr bestätigt werden müssen, ist noch etwas gewöhnungsbedürftig. :-)

        --
        Verschiedene Glocken läuteten in der Stadt, und jede von ihnen vertrat eine ganz persönliche Meinung darüber, wann es Mitternacht war. Terry Pratchett, “Wachen! Wachen!
        1. Tach!

          PS: Dass hier allerlei Mumpitz als Tags angeboten wird, ist ja ganz witzig und bietet Spielraum. Dass seit heute eindeutige Tags angelegt und nicht mehr bestätigt werden müssen, ist noch etwas gewöhnungsbedürftig. :-)

          "Seit heute" liegt an deinen 500 Punkten.

          dedlfix.

          1. Hallo dedlfix,

            PS: Dass hier allerlei Mumpitz als Tags angeboten wird, ist ja ganz witzig und bietet Spielraum. Dass seit heute eindeutige Tags angelegt und nicht mehr bestätigt werden müssen, ist noch etwas gewöhnungsbedürftig. :-)

            "Seit heute" liegt an deinen 500 Punkten.

            Nein, das liegt daran, dass ich das heute erst eingebaut habe ;-)

            LG,
            CK

          2. Hallo

            PS: … Dass seit heute eindeutige Tags angelegt und nicht mehr bestätigt werden müssen, ist noch etwas gewöhnungsbedürftig. :-)

            "Seit heute" liegt an deinen 500 Punkten.

            Den Sachverhalt hat Christian ja schon klargestellt. Jetzt musste ich das auch gleich einmal ausprobieren. Ich denke mal, meinem vorhergehenden Posting als Spielerei das Tag „spielerei“ hinzuzufügen, kann man bei einem auch als „menschelei“ gekennzeichneten Posting mal machen.

            Tschö, Auge

            --
            Verschiedene Glocken läuteten in der Stadt, und jede von ihnen vertrat eine ganz persönliche Meinung darüber, wann es Mitternacht war. Terry Pratchett, “Wachen! Wachen!
      4. Moin!

        Aha. Um Diskussion und Fehlersuche zu bitten macht keinen Sinn. Einfach Fehler einbauen und warten bis sich der erste meldet ... so kommt die erwünschte Diskussion in jedem Fall zu Stande :)

        Jörg Reinholz