Jörg Reinholz: Artikel: PHP/Tutorials/Dateien mittels include einbinden

Liebe Freunde der böhmischen Blasmusik!

Ich bin über den Artikel "PHP/Tutorials/Dateien mittels include einbinden" gestolpert, habe das Gefühl gehabt, dass der irgendwie zu sehr unvollständig war ihn mir deshalb ein wenig "vorgenommen".

Bitte gegenlesen. Danke.

Jörg Reinholz

  1. Hallo

    Ich bin über den Artikel "PHP/Tutorials/Dateien mittels include einbinden" gestolpert, habe das Gefühl gehabt, dass der irgendwie zu sehr unvollständig war ihn mir deshalb ein wenig "vorgenommen".

    Bitte gegenlesen. Danke.

    Ich habe ein paar Fehler im Satzbau korrigiert (ein paar Worte an der falschen Stelle bzw. zu viel, ein paar Kommata zu wenig).

    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!" ie:{ fl:| br:> va:) ls:[ fo:) rl:( ss:| de:> js:| zu:}
    1. Ich habe ein paar Fehler im Satzbau korrigiert (ein paar Worte an der falschen Stelle bzw. zu viel, ein paar Kommata zu wenig).

      Jepp. Danke: Deswegen habe ich ich den Thread eröffnet.

      Jörg Reinholz

      1. Jepp. Danke: Deswegen habe ich ich den Thread eröffnet.

        Falls es nicht zu weit geht wären ein paar Worte zur Absicherung von include($_GET['uebergabewert']); interessant...

        1. Falls es nicht zu weit geht wären ein paar Worte zur Absicherung von include($_GET['uebergabewert']); interessant...

          Ja, ich bin dem aus den Weg gegangen. Womöglich schreibe ich an anderer Stelle etwas darüber, denn es gibt zwar "PHP in HTML" und "HTML in PHP" aber nichts zum Thema "Templates". Dort wäre es, so finde ich, angebrachter und wir können nicht aus jedem Wiki-Beitrag ein komplettes Buch über PHP machen, weil dann jeder Lerneffekt weg ist.

          Jörg Reinholz

        2. Jepp. Danke: Deswegen habe ich ich den Thread eröffnet.

          Falls es nicht zu weit geht wären ein paar Worte zur Absicherung von include($_GET['uebergabewert']); interessant...

          Erledigt, Siehe:

          Jörg Reinholz

  2. Vielen Dank für die viele und gute Arbeit, die Du ins Wiki steckst. Deine Beiträge sind eine Bereicherung!

    Herzliche Grüße Matthias

  3. Liebe Mitdenker, liebe Wissende, liebe Neugierige,

    ja!

    Ich bin über den Artikel "PHP/Tutorials/Dateien mittels include einbinden" gestolpert, habe das Gefühl gehabt, dass der irgendwie zu sehr unvollständig war ihn mir deshalb ein wenig "vorgenommen".

    Da fehlen noch wesentliche Dinge, wie

    • Zugriffsrechte (z.B. openbasedir, ...)
    • Zugriffspfade mit Sonderrechten (z.B. include_path)

    Spirituelle Grüße Euer Robert

    --
    Möge der Forumsgeist wiederbelebt werden!
    1. Moin!

      Da fehlen noch wesentliche Dinge, wie

      • Zugriffsrechte (z.B. openbasedir, ...)

      Abschnitt "Ein Wort zur Sicherheit: Externe Quellen für den Name der zu incluierenden Datei sind gefährlich!" eingefügt.

      • Zugriffspfade mit Sonderrechten (z.B. include_path)

      Du bist nicht daran gehindert, da was beizutragen.

      Jörg Reinholz

      1. Ich spamme jetzt doch maL:

        Ich habe einen  Abschnitt "Ein Wort zur Sicherheit: Externe Quellen für den Name der zu incluierenden Datei sind gefährlich!" eingefügt.

        Da es a) sicherheistkritisches Zeug ist und b) im SelfHTML-Wiki steht wäre es gut, wenn es eine Qualitätskontrolle gäbe.

        Jörg Reinholz

        1. Liebe Mitdenker, liebe Wissende, liebe Neugierige,

          ja!

          Ich habe einen  Abschnitt "Ein Wort zur Sicherheit: Externe Quellen für den Name der zu incluierenden Datei sind gefährlich!" eingefügt.

          Das versteht kaum Einer mehr, schon gar nicht ein Neuling.

          Das PHP "open_basedir" nun auf PHP_INI_ALL gesetzt hat, ist ein Armutszeugnis. Was hat ein Skript an der Grundkonfiguration zu ändern?

          Da hilft dann hoffentlich noch das

          
              php_admin_value open_basedir /var/www/domain/
          
          
          

          Es gab hier auch mal einen recht umfangreichen Artikel über das File-Upload / File-Download (im Wiki ?), der noch nicht ganz fertig war, aber durch den ich eine Menge gelernt habe. Leider ist der verschwunden. Oder ich habe mir nicht richtig gemerkt, wo der gespeichert ist. Ich hätte gerne noch ein paar Absätze dazu beigetragen.

          Spirituelle Grüße Euer Robert

          --
          Möge der Forumsgeist wiederbelebt werden!
          1. Tach!

            Das PHP "open_basedir" nun auf PHP_INI_ALL gesetzt hat, ist ein Armutszeugnis. Was hat ein Skript an der Grundkonfiguration zu ändern?

            Wenn ich die Dokumentation richtig lese, ist das kein Aufweichen.

            "As of PHP 5.3.0 open_basedir can be tightened at run-time. This means that if open_basedir is set to /www/ in php.ini a script can tighten the configuration to /www/tmp/ at run-time with ini_set(). When listing several directories, you can use the PATH_SEPARATOR constant as a separator regardless of the operating system."

            Man kann nicht aus den per Vorgabe freigegebenen Verzeichnissen befreien, man kann sich nur die Schlinge um den Hals fester zuziehen.

            dedlfix.

            1. Liebe Mitdenker, liebe Wissende, liebe Neugierige,

              ja!

              Das PHP "open_basedir" nun auf PHP_INI_ALL gesetzt hat, ist ein Armutszeugnis. Was hat ein Skript an der Grundkonfiguration zu ändern?

              Wenn ich die Dokumentation richtig lese, ist das kein Aufweichen.

              "As of PHP 5.3.0 open_basedir can be tightened at run-time. This means that if open_basedir is set to /www/ in php.ini a script can tighten the configuration to /www/tmp/ at run-time with ini_set(). When listing several directories, you can use the PATH_SEPARATOR constant as a separator regardless of the operating system."

              Man kann nicht aus den per Vorgabe freigegebenen Verzeichnissen befreien, man kann sich nur die Schlinge um den Hals fester zuziehen.

              Etwas schwer verständlich dokumemntiert. Man muss scheinbar wirklich alles immer wieder selber ausprobieren :-((

              Spirituelle Grüße Euer Robert

              --
              Möge der Forumsgeist wiederbelebt werden!
          2. Om nah hoo pez nyeetz, Robert R.!

            Es gab hier auch mal einen recht umfangreichen Artikel über das File-Upload / File-Download (im Wiki ?), der noch nicht ganz fertig war, aber durch den ich eine Menge gelernt habe. Leider ist der verschwunden. Oder ich habe mir nicht richtig gemerkt, wo der gespeichert ist. Ich hätte gerne noch ein paar Absätze dazu beigetragen.

            http://wiki.selfhtml.org/wiki/ArtikelPHP/File-Upload

            Prima, dass du dich beteiligen willst.

            Matthias

            --
            Der Unterschied zwischen Java und JavaScript ist größer als der zwischen Brand und Brandenburg. http://www.billiger-im-urlaub.de/kreis_sw.gif
          3. Das versteht kaum Einer mehr, schon gar nicht ein Neuling.

            Meinst jetzt den Abschnitt im Wiki oder das Folgende:

            Das PHP "open_basedir" nun auf PHP_INI_ALL gesetzt hat, ist ein Armutszeugnis. Was hat ein Skript an der Grundkonfiguration zu ändern?

            Nun ja. Wie dedlfix schon sagte, man kann die Schlinge enger ziehen. Die Sache ist letztendlich die: Man hat einen (virtuellen) Host, für den erst einmal eine bestimmte Konfiguration gilt.

            Jetzt hat man da eine Webseite. Nehmen wir an, diese wird mittels eines CMS mit Inhalten gefüllt. Damit haben wir (genau genommen) mindestens drei Bereiche:

            • Benutzerteil ("Die öffentliche Webseite")
            • Bedienung des CMS
            • Benutzeradministration für die Bedienung des CMS

            Das trifft auch dann zu, wenn die Bedienung des CMS und die Benutzeradministration optisch(!) übereinstimmen oder gar, um den Aufwand zu vermeiden, vom Ideal abgewichen wird. Nehmen wir als Beispiel die Session. An eine solche werden im Beispiel höchst unterschiedliche Anforderungen zu stellen sein: Um im CMS eine Seite zu bearbeiten ("Bedienung des CMS ") muss man eine längere Inaktivität zulassen. Das ist aber hinsichtlich der Benutzeradministration des CMS aber gewiss keine gute Idee!

            Damit sollte Deine Frage "Was hat ein Skript an der Grundkonfiguration zu ändern?" geklärt sein.

            Kommen wir zum beklagten "Das versteht kaum Einer mehr, schon gar nicht ein Neuling."

            Das ist halt so und ein Neuling kann nicht erwarten, dass mit einem einfachen make_safe(all.this); alle von ihm verursachten oder übersehenen Probleme erschlagen werden. Du hast ja gesehen, was für einen Aufwand man u.U. treiben muss um per GET übergebene Parameter zu bearbeiten, bis ein halbwegs sicheres include mit diesen möglich ist. In der Autowerkstatt wir man (ich weiß: das geschieht manchmal doch) auch nicht die Arbeit von Praktikanten und Azubis auf die Straße rollen lassen ohne die durch einen Facharbeiter oder Meister zu prüfen. Wenn die jetzt aber am Wochenende irgendwo rumschrauben und dabei Murks bauen, dann ist nicht der Werkzeugkasten, die Hebebühne oder das Schweißgerät schuld. Auf Deutsch: Wenn ein Neuling meint, er könne irgendwelches sicherheitskritisches Zeug programmieren, dann übernimmt er sich einfach.

            Wie auch immer, es kann und wird erforderlich sein, dass die oben genannten 3 Bereiche eines CMS unterschiedliche Konfigurationen benötigen. Leider, und in dem Punkt hast Du recht, wird es völlig unübersehbar und letztendlich nervend, wenn man dann auch noch einen "shared host" hat, weil verschiedene Hoster (wohl infolge höchst verschiedener, von Kunden verursachter Katastrophen) höchst unterschiedliche Vorstellungen haben, was diese den Kunden erlauben und was nicht.

            Beispiel:

            Ich weiß zum Beispiel nicht so recht, was mein Hoster gemacht hat (oder ob das ein BUG in der verwendeten PHP-Version ist, aber [wenn ich im Login-System ein eigenes Verzeichnis für die Sessiondateien einrichte und dann die Session mit (http://wiki.selfhtml.org/wiki/PHP/Anwendung_und_Praxis/Loginsystem#Die_Ressource_logout.php)session_destroy() "kille"], bleibt das bei meinem Hoster (anders als auf allen meinen Testsystemem) völlig wirkungslos. Ich muss allen Ernstes mit:

            unlink ( SESSION_FILE_DIR . '/sess_' . session_id());
            #SESSION_FILE_DIR ist eigene Konstante
            

            die Session-Datei quasi manuell löschen, was übrigens völlig undokumentiert ist.

            Im Beispiel führt, wenn man das nicht bemerkt, genau das zu einem Sicherheitsproblem, weil das Abmelden völlig wirkungsfrei bleibt und die Sitzung selbst nach einem vermeintlich explizitem Logout weiter gültig bleibt!

            Aber das ist halt so. Wenn in englischen Wagen das Lenkrad nicht da ist, wo ein Deutscher es erwartet, dann muss er eben nach dem Einsteigen und staunen nochmal rüberrutschen und schauen, wie er das mit dem Bedienkram hinkriegt...

            Jörg Reinholz

      2. Liebe Mitdenker, liebe Wissende, liebe Neugierige,

        ja!

        • Zugriffspfade mit Sonderrechten (z.B. include_path) Du bist nicht daran gehindert, da was beizutragen.

        Nicht bevor ich erkennen kann, dass Du damit fertig bist. Einfach nur drin rumschmieren in anderer Autoren Artikel ist nicht die feine Art.

        Setz einen Punkt rein in das Inhaltsverzeichnis zu dem Thema mit dem Vermerk "extern" und ich schreibe was.

        Dem Wiki hier fehlt noch die Kultur. Keiner weiß, wer wann was schreiben darf. Technische Wikis sind nicht direkt vergleichbar mit dem allgemeinen Wiki üer Gott und die Welt.

        Spirituelle Grüße Euer Robert

        --
        Möge der Forumsgeist wiederbelebt werden!
        1. Tach!

          • Zugriffspfade mit Sonderrechten (z.B. include_path) Du bist nicht daran gehindert, da was beizutragen. Nicht bevor ich erkennen kann, dass Du damit fertig bist. Einfach nur drin rumschmieren in anderer Autoren Artikel ist nicht die feine Art.

          Es gibt zu jeder Seite eine Diskussionsseite.

          Dem Wiki hier fehlt noch die Kultur. Keiner weiß, wer wann was schreiben darf.

          Vielleicht sollten wir die Vorlage zur direkten Autorenangabe aus den Artikeln entfernen. Es ist ja aus der History einer Seite ersichtlich, wer alles mitgearbeitet hat (außer sie wurden aus dem alten Selfhtml von jemand anderem ins Wiki kopiert). Je nach Umfang der Mitarbeit wird ja auch die Angabe des ursprünglichen Autors immer weniger richtig.

          Man könnte zur Faustregel machen, wenn etwas im Benutzernamensraum steht, dann sollte man den Autor bei seiner Arbeit nicht stören (außer Kleinigkeiten wie Rechtschreibfehler). Wenn es in anderen steht, ist es freigegeben.

          dedlfix.

        2. Dem Wiki hier fehlt noch die Kultur. Keiner weiß, wer wann was schreiben darf. Technische Wikis sind nicht direkt vergleichbar mit dem allgemeinen Wiki üer Gott und die Welt.

          Hm. Ich habe das jetzt mal konkretisiert:

          Die Autorenbox im Abschnitt zu include, require, include_once bzw. require_once habe ich entfernt, weil den Teil halte ich für "gut durchkorrigiert", Auderdem sollte es da keine Sicherheitsprobleme geben.

          Vor die Autorenbox im Abschnitt "Ein Wort zur Sicherheit: Externe Quellen für den Namen der zu includierenden Datei sind gefährlich!" habe ich zur Klarstellung eingefügt:

          "Fehler in diesem Abschnitt bitte korrigieren oder, wenn Sie sich das nicht zutrauen, per Email melden."

          Ich denke, dass damit klar ist, dass ich den Abschnitt nicht als ein "Reich" ansehe, in welchem ich herrsche.

          Jörg Reinholz

  4. Liebe Mitdenker, liebe Wissende, liebe Neugierige,

    ja!

    und noch ein Kritikpunkt:

    
        PHP? <?php echo 'Funktioniert! Version ist:', phpversion(), "\n"; ?>
    
    
    

    da es zu 99% um mdas HTML-Umfeld handelt, sollte man sich angewöhnen,

    
        PHP? <?php echo 'Funktioniert! Version ist:', phpversion(), "\r\n"; ?>
    
    
    

    zu schreiben. HTML wünscht ein vollstämndiges CR-LF zu haben.

    Spirituelle Grüße Euer Robert

    --
    Möge der Forumsgeist wiederbelebt werden!
    1. Hallo,

      HTML wünscht ein vollstämndiges CR-LF zu haben.

      aber mitnichten, und mitneffen schon gar nicht. Ob CR oder LF oder beides zusammen, ist HTML sowas von wurscht. Beide Zeichen gelten als Whitespace und werden auf ein Leerzeichen reduziert, wenn sie in Paaren oder Rudeln auftreten.

      Ciao,  Martin

      --
      Sozial ist, wenn andere bezahlen. Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
      1. Liebe Mitdenker, liebe Wissende, liebe Neugierige,

        ja!

        Hallo,

        HTML wünscht ein vollstämndiges CR-LF zu haben.

        aber mitnichten, und mitneffen schon gar nicht. Ob CR oder LF oder beides zusammen, ist HTML sowas von wurscht. Beide Zeichen gelten als Whitespace und werden auf ein Leerzeichen reduziert, wenn sie in Paaren oder Rudeln auftreten.

        "when it is done consistently for an entire entity-body"

        sonst gilt CRLF!

        Das hat nichts mit der vorgeschriebenen Toleranz für nur CR oder nur LF zu tun. Erst einmal richtig™ machen, die Ausnahmen kommen dann später!

        Spirituelle Grüße Euer Robert

        --
        Möge der Forumsgeist wiederbelebt werden!
        1. Mahlzeit,

          HTML wünscht ein vollstämndiges CR-LF zu haben. aber mitnichten, und mitneffen schon gar nicht. Ob CR oder LF oder beides zusammen, ist HTML sowas von wurscht. Beide Zeichen gelten als Whitespace und werden auf ein Leerzeichen reduziert, wenn sie in Paaren oder Rudeln auftreten. "when it is done consistently for an entire entity-body"

          wo hast du den Halbsatz her? Mich beschleicht nämlich gerade der Verdacht, du hattest nicht HTML, sondern HTTP gemeint. Denn in den protokollrelevanten Teilen von HTTP (Header, AFAIK auch die lokalen Header von sub-parts) ist tatsächlich CR+LF angesagt, in der Nutzlast (Request/Response Body) spielt es vom HTTP-Standpunkt dagegen keine Rolle.

          Das hat nichts mit der vorgeschriebenen Toleranz für nur CR oder nur LF zu tun.

          Nein, ich sprach auch nicht von Toleranz oder etwas in der Art - nur davon, dass HTML keinen Unterschied zwischen CR, LF, Tab und Space macht. Alle diese Zeichen haben für HTML dieselbe Bedeutung, und wo mehrere von ihnen zusammentreffen, werden sie wie ein einzelnes behandelt.

          Erst einmal richtig™ machen, die Ausnahmen kommen dann später!

          Völlig okay. Davon konnte aber hier keine Rede sein.

          Ciao,  Martin

          --
          Der Stress von heute ist die gute alte Zeit von morgen. Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
    2. Hakuna matata!

      HTML wünscht ein vollstämndiges CR-LF zu haben.

      „Newlines in HTML may be represented either as "CR" (U+000D) characters, "LF" (U+000A) characters, or pairs of "CR" (U+000D), "LF" (U+000A) characters in that order.“ Quelle: http://www.w3.org/TR/html51/syntax.html#newlines

      --
      “All right, then, I'll go to hell.” – Huck Finn
    3. Nein. Denn bei einer Ausgabe im Browser ist es völlig ohne Bedeutung - schon mal deswegen, weil danach NICHTS folgt.

      Wenn schon "HTML-Umfeld" dann wäre ein <br> angebracht, was ich aber vermeide, weil ich so kleine Tests stets in der Konsole/Terminal/ssh-Sitzung vornehme und da ist das "\n" goldrichtig um den nachfolgenden Prompt von der Ausgabe zu trennen. <br> ist da vergebene Mühe...

      Jörg Reinholz