Dynamische Textarea auslesen

[Richie]

Hallo

ich habe anscheinend gerade ein Brett vorm Kopf...

Ich lese aus MySQL Texte aus und erstelle daraus dynamisch Textareas:

  
<textarea name="meintext[<?php echo $id ?>]"><?php echo $meintext ?></textarea>  

So weit so gut.

Nach dem Absenden werden die Formularfelder verarbeitet und die Textareas - so der Plan - mittels foreach-Schleife ausgelesen und wieder in der DB gespeichert:

  
foreach ($meintext as $key => $value) {  
// Datenbank-Insert...  
}  

$meintext kommt aber nicht als Array an und ich kapier nicht wieso... wo ist mein Denkfehler?

[Der Martin]

Hi,

ich habe anscheinend gerade ein Brett vorm Kopf...

das kann sein; wahrscheinlicher ist aber, dass du nur den Anfang und das Ende eines Rohrs anschaust und dich wunderst, warum kein Wasser durchläuft - dabei sollte man das Rohr vielleicht nur mal Stück für Stück verfolgen.

Ich lese aus MySQL Texte aus und erstelle daraus dynamisch Textareas:

<textarea name="meintext[<?php echo $id ?>]"><?php echo $meintext ?></textarea>

So weit so gut.

Wirklich gut? Was kommt den tatsächlich beim Client an? Kontrolliere das, und überlege, ob es das ist, was du erwartest.

Nach dem Absenden werden die Formularfelder verarbeitet und die Textareas - so der Plan - mittels foreach-Schleife ausgelesen und wieder in der DB gespeichert:

foreach ($meintext as $key => $value) {

// Datenbank-Insert...
}

>   
> $meintext kommt aber nicht als Array an und ich kapier nicht wieso... wo ist mein Denkfehler?  
  
Kommen denn die Daten im $\_GET- oder $\_POST-Array an (vorzugsweise $\_POST), so wie erwartet? Nachprüfen!  
Wo (und warum) kopierst du die Daten dann von $\_POST['meintext'] nach $meintext um? Geht dabei etwas schief? Nachprüfen!  
  
Debugging heißt, den Programmablauf und die Veränderung von Daten Schritt für Schritt zu verfolgen und so die Stelle aufzuspüren, an der etwas aus dem Ruder läuft. Ja, das ist manchmal stumpf und zeitraubend, aber unvermeidbar.  
  
So long,  
 Martin  

-- 
Niemand ist überflüssig: Er kann immer noch als schlechtes Beispiel dienen.  
Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(

[Robert R.]

Liebe Mitdenker,
liebe Wissende,
liebe Neugierige,

Ich lese aus MySQL Texte aus und erstelle daraus dynamisch Textareas:

<textarea name="meintext[<?php echo $id ?>]"><?php echo $meintext ?></textarea>

>   
> So weit so gut.  
  
Nö, das ist gar nicht gut. Da fehlt die Kontextbehandlung.  
  
  
Spirituelle Grüße  
Euer Robert

-- 
Möge der Forumsgeist wiederbelebt werden!

[Gunnar Bittersmann]

@@Robert R.:

nuqneH

So weit so gut.

Nö, das ist gar nicht gut. Da fehlt die Kontextbehandlung.

Und du glaubst ernsthaft, dass Richie mit _der_ Antwort was anfangen kann?

Qapla'

PS: Wo ist der „Nicht hilfreich“-Button?

[Robert R.]

Liebe Mitdenker,
liebe Wissende,
liebe Neugierige,

ja!

Nö, das ist gar nicht gut. Da fehlt die Kontextbehandlung.

Und du glaubst ernsthaft, dass Richie mit _der_ Antwort was anfangen kann?

Mit Google wird er ja wohl umgehen können?
Suche "hrml Kontextbehandlung"
ERSTER Treffer:
http://wiki.selfhtml.org/wiki/PHP/Anwendung_und_Praxis/Kontextwechsel

Spirituelle Grüße
Euer Robert

[Gunnar Bittersmann]

@@Robert R.:

nuqneH

Nö, das ist gar nicht gut. Da fehlt die Kontextbehandlung.

Und du glaubst ernsthaft, dass Richie mit _der_ Antwort was anfangen kann?

Mit Google wird er ja wohl umgehen können?
Suche "hrml Kontextbehandlung"

Aus deiner Antwort ging nicht im Geringsten hervor, was dein eigentlich das Problem darstellt und warum man überhaupt nach etwas goo^W suchen* sollte.

ERSTER Treffer:
http://wiki.selfhtml.org/wiki/PHP/Anwendung_und_Praxis/Kontextwechsel

Ja, und dann?

Der Artikel ist lang und recht abstrakt. Läd jemanden, der sich der Problematik nicht bewusst ist, kaum zum Lesen ein.

Außerdem wird das hier vorliegende Problem überhaupt nicht behandelt. (Er behandelt SQL-Injections und " in Zeichenketten. Dabei gibt er den falschen Rat, " zu escapen. Richtig wäre der Rat, richtige Anführungszeichen (de: „“, en: “”) zu verwenden; dann taucht das Problem gar nicht erst auf.)

Erst ganz unten im Artikel (d.h. ein an SQL nicht Interessierter wird gar nicht bis dorthin kommen) findet sich ein Link zur Fortsetzung Kontextwechsel erkennen und behandeln. Dort erst wird auf htmlspecialchars() eingegangen. Allerdings ohne die Problematik XSS-Injections zu erwähnen. Es wird lediglich gesagt, wie man Ausgaben in HTML behandeln _kann_; kein Wort darüber, warum man das tun _muss_.

Fazit: Die Artikel zum Kontextwechsel sind wenig geeignet, Anfängern (und unwissenden Fortgeschrittenen) die Problematik zu vermitteln. Sie sollten grundlegend überarbeitet werden.

Qapla'

* Ein erster Schrittgegen Spyware 2.0 ist die Erkenntnis, dass es außer der Datenkrake Google noch andere Suchmaschinen gibt. DuckDuckGo bspw.

[dedlfix]

Tach!

Erst ganz unten im Artikel (d.h. ein an SQL nicht Interessierter wird gar nicht bis dorthin kommen) findet sich ein Link zur Fortsetzung Kontextwechsel erkennen und behandeln. Dort erst wird auf htmlspecialchars() eingegangen. Allerdings ohne die Problematik XSS-Injections zu erwähnen. Es wird lediglich gesagt, wie man Ausgaben in HTML behandeln _kann_; kein Wort darüber, warum man das tun _muss_.

Deswegen gibt es ja den Einführungsteil, der beschreibt die generelle Problematik und zeigt auch was passiert, wenn man das nicht macht. Daraus ergibt sich von selbst, dass man was tun muss, wenn man dieses Problem nicht haben möchte. Als (Haupt-)Autor liegt es mir fern, dem Leser Vorschriften zu machen. Ich zeige das Problem und beschreibe Wege, die man zur Vermeidung tun kann. Es ist kein Muss, die Funktion htmlspecialchars() zu verwenden. Je nach Framework/Umgebung kann es da andere Wege geben.

Fazit: Die Artikel zum Kontextwechsel sind wenig geeignet, Anfängern (und unwissenden Fortgeschrittenen) die Problematik zu vermitteln. Sie sollten grundlegend überarbeitet werden.

Und nun bitte die konstruktiven Vorschläge. Zum Beispiel eine 140-Zeichen-TL;DR-Fassung.

dedlfix.

[Richie]

Danke, das mit htmlspecialchars() ist mir klar.
Habs hier nur der Einfachheit wegen weggelassen - sorry, falls das für Verwirrung stiftete ;-)

Das Problem hat sich inzwischen gelöst (siehe meinen Beitrag von gestern).
Aber DANKE nochmal!

[Gunnar Bittersmann]

@@dedlfix:

nuqneH

Deswegen gibt es ja den Einführungsteil, der beschreibt die generelle Problematik und zeigt auch was passiert, wenn man das nicht macht.

Zur Einführung ist " in "" nicht schlecht. Da sollte aber dabeistehen, dass man im Text typographisch richtige (ohne [tm]) Anführungszeichen verwenden sollte – nicht nur aus dem Grund, dass dann nicht escapet werden muss.

Das SQL-Teil sollte in einem gesonderten Artikel behandelt werden. Einsteiger werden eher mit HTML und PHP (ohne DB) zu tun haben.

Vielleicht solch ein Beispiel: Wenn der URI http://example.net/?a=b&auml=c in den HTML-Kontext gebracht wird (href-Attribut), muss das & entsprechend escapet werden (&amp;), weil der Parser sonst http://example.net/?a=bü=c liest.

Wenn example&co in den Query-Kontext gebracht wird, muss das & entsprechend escapet werden (%26), weil der Parser es in http://example.net/?q=example&co sonst als Trennzeichen zwischen Paramertern liest.

Am Beispiel <a href="http://example.net/?a=b&amp;q=example%26co"> kann man nochmal verdeutlichen, wie dasselbe Zeichen & in verschiedenen Kontexten jeweils entsprechend escapet wird.

Daraus ergibt sich von selbst, dass man was tun muss, wenn man dieses Problem nicht haben möchte.

Die Gefahr von XSS finde ich in den Artiklen nicht erwähnt. Dem Entwickler mag die Gefahr gar nicht bewusst sein (1000fach hier im Forum). Es ist ja auch kein Fehler, den irgendein Parser melden könnte.

Qapla'

[ChrisB]

Hi,

Zur Einführung ist " in "" nicht schlecht. Da sollte aber dabeistehen, dass man im Text typographisch richtige (ohne [tm]) Anführungszeichen verwenden sollte – nicht nur aus dem Grund, dass dann nicht escapet werden muss.

So ein Quatsch. *Das* ist absolut nicht Gegenstand des Artikels (den du gerade vorher noch als „zu lang“ für Anfänger bezeichnet hast).

Das SQL-Teil sollte in einem gesonderten Artikel behandelt werden. Einsteiger werden eher mit HTML und PHP (ohne DB) zu tun haben.

Auch nicht korrekt. Fragen zu (My-)SQL-Abfragen, in denen jedwede Maßnahmen gegen SQL-Injection vernachlässigt wurden, sind sowohl hier als auch in anderen Foren gang und gäbe – auch und gerade von Anfängern.

(Wenn es in der Hinsicht etwas zu kritisieren gäbe, dann höchstens dass der Hinweis, dass die mysql-Funktionen deprecated sind, fehlt. Der ist für die Thematik relevant, im Gegensatz zu deinen deutschen Anführungszeichen …)

Vielleicht solch ein Beispiel: Wenn der URI http://example.net/?a=b&auml=c in den HTML-Kontext gebracht wird (href-Attribut), muss das & entsprechend escapet werden (&amp;), weil der Parser sonst http://example.net/?a=bü=c liest.

Ausgerechnet von dir eine Argumentation für fehlerhafte Parser …?

(Ja, einer der das ohne das abschließende Semikolon als ü interpretiert, wäre m.E. fehlerhaft – oder hat HTML5 das inzwischen als häufig vorkommenden Fehler, der entsprechend zu behandeln ist, spezifiziert?)

Die Gefahr von XSS finde ich in den Artiklen nicht erwähnt.

Wird hier: http://wiki.selfhtml.org/wiki/Artikel:Kontextwechsel/erkennen_und_behandeln#JavaScript kurz angesprochen. Ja, ist unterrepräsentiert und wäre ausbaufähig. Allerdings ist *das* eine hinreichend komplexe Thematik, für die ein eigenständiger Artikel gerechtfertigt wäre.

MfG ChrisB

[Der Martin]

Hallo,

Ausgerechnet von dir eine Argumentation für fehlerhafte Parser …?
(Ja, einer der das ohne das abschließende Semikolon als ü interpretiert, wäre m.E. fehlerhaft – oder hat HTML5 das inzwischen als häufig vorkommenden Fehler, der entsprechend zu behandeln ist, spezifiziert?)

ich meine mich zu erinnern, dass diese Fehlertoleranz bereits in SGML festgelegt ist - dass der Bezeichner für eine Entity-Referenz in jedem Fall beim ersten non-word-character endet, auch wenn das kein Semikolon ist.

Ciao,
 Martin

[Gunnar Bittersmann]

@@ChrisB:

nuqneH

(Ja, einer der das ohne das abschließende Semikolon als ü interpretiert, wäre m.E. fehlerhaft

Nein.

oder hat HTML5 das inzwischen als häufig vorkommenden Fehler, der entsprechend zu behandeln ist, spezifiziert?)

Njein.

Ja, spezifiziert. HTML5 schreibt ein abschließendes Semikolon vor; sagt aber auch, wie zu verfahren ist, wenn kein solches vorliegt.

Nein, nicht inzwischen. Das war auch schon im guten alten HTML so: „In SGML, it is possible to eliminate the final ";" after a character reference in some cases…“

Qapla'

[Gunnar Bittersmann]

@@ChrisB:

nuqneH

Da sollte aber dabeistehen, dass man im Text typographisch richtige (ohne [tm]) Anführungszeichen verwenden sollte – nicht nur aus dem Grund, dass dann nicht escapet werden muss.

So ein Quatsch. *Das* ist absolut nicht Gegenstand des Artikels (den du gerade vorher noch als „zu lang“ für Anfänger bezeichnet hast).

Au contraire, mon capitaine! Gerade an Anfänger gerichtete Artikel sollten nicht stupide ein begrenztes Gebiet beackern, sondern immer über den Tellerrand hinausschauen. Wie sollten die sonst auf Gebiete stoßen, die außerhalb ihrer bisherigen Welt liegen?

Artikel für Einsteiger müssen nicht so sehr in die Tiefe, dafür umso mehr in die Breite gehen. Sonst züchten wir die nächste Generation von denen heran, wovon es schon genügend gibt: Fachidioten.

Qapla'

[ChrisB]

Hi,

Artikel für Einsteiger müssen nicht so sehr in die Tiefe, dafür umso mehr in die Breite gehen.

Es handelt sich um einen Artikel zu einem technischen Thema, und du meinst unbedingt etwas völlig themenfremdes hinein bringen zu müssen – das ist kein *sinnvolles* „in die Breite gehen“ mehr, das ist ein Verwässern und Aufblähen mit – für das Thema des Artikels – völlig unnützem Quatsch.

MfG ChrisB

[Gunnar Bittersmann]

@@ChrisB:

nuqneH

Es handelt sich um einen Artikel zu einem technischen Thema, und du meinst unbedingt etwas völlig themenfremdes hinein bringen zu müssen

Ja, genau das meine ich mit „Wie sollten die [Einsteiger] sonst auf Gebiete stoßen, die außerhalb ihrer bisherigen Welt liegen?“

das ist kein *sinnvolles* „in die Breite gehen“ mehr, das ist ein Verwässern und Aufblähen mit – für das Thema des Artikels – völlig unnützem Quatsch.

Wenn du Typographie tatsächlich für völlig unnützen Quatsch hältst, solltest du dich dem Backend oder auch der JavaScript-Programmierung widmen, dich aber ansonsten von Frontend-Entwicklung fernhalten.

Außerdem gehört die Vermeidung von Escapes durchaus zum Thema Escapes dazu.

Qapla'

[dedlfix]

Tach!

Außerdem gehört die Vermeidung von Escapes durchaus zum Thema Escapes dazu.

Es ist viel mehr Aufwand, jedes Mal darüber nachzudenken und vor allem sicherzustellen, ob und dass typografische Zeichen verwendet werden oder nicht. Zudem gibt es für <, > und & keine typografischen "Ersatz"zeichen. Du kommst nicht generell um ein Maskieren umhin, nur weil du typografische Anführungszeichen nimmst. Sie zu verwenden ist nicht problemlösend.

dedlfix.

[Gunnar Bittersmann]

@@dedlfix:

nuqneH

Es ist viel mehr Aufwand, jedes Mal darüber nachzudenken und vor allem sicherzustellen, ob und dass typografische Zeichen verwendet werden oder nicht.

Verstehe ich nicht. Die Frage nach dem Ob und dem Dass lässt sich ohne Aufwand mit ja beantworten.

(Es sei denn, man verwendet eine andere Zeichencodierung als UTF-8. Aber das tut man nicht.)

Zudem gibt es für <, > und & keine typografischen "Ersatz"zeichen.

<, > sind in SGML/XML/HTML schon „Ersatz“zeichen – für spitze Klammer auf/zu. Für ⟨ ⟩.

Du kommst nicht generell um ein Maskieren umhin, nur weil du typografische Anführungszeichen nimmst. Sie zu verwenden ist nicht problemlösend.

Natürlich löst die Verwendung von „“ (“”) nicht das Problem des Escapens von <, > und &.

Aber das des Escapens von ". Was besonders problematisch ist, weil " den Quelltext besonders unübersichtlich macht, da es – im Gegensatz zu <, > u.(a.) Klammern – sowohl als öffnendes als auch als schließendes Zeichen verwendet wird.

(Entsprechendes gilt für einfache Anführungszeichen/Apostrophe.)

Aber in einem äußerte ich mich missverständlich, als ich schrieb

… »» Da sollte aber dabeistehen, dass man im Text typographisch richtige (ohne [tm]) Anführungszeichen verwenden sollte – nicht nur aus dem Grund, dass dann nicht escapet werden muss.

Dass nicht escapet werden muss, ist kein _Grund_ für die Verwendung typographisch richtiger Anführungszeichen. Der Grund dafür ist, dass den Nutzern der Inhalt besser präsentiert wird.

Dass dann nicht escapet werden muss, ist ein äußerst nützlicher Nebeneffekt.

Qapla'

[Gunnar Bittersmann]

@@Gunnar Bittersmann:

nuqneH

Aber in einem äußerte ich mich missverständlich, als ich schrieb

… »» Da sollte aber dabeistehen, dass man im Text typographisch richtige (ohne [tm]) Anführungszeichen verwenden sollte – nicht nur aus dem Grund, dass dann nicht escapet werden muss.

Doch im anderen äußerte ich mich doch klar und deutlich: „dabeistehen“.

Es ging nicht um ein „Verwässern und Aufblähen“, wie ChrisB polemisierte. Ich hatte keinen ganzen Abschnitt dafür im Sinn, sondern eins, zwei Sätze.

Qapla'

[dedlfix]

Tach!

Es ist viel mehr Aufwand, jedes Mal darüber nachzudenken und vor allem sicherzustellen, ob und dass typografische Zeichen verwendet werden oder nicht.
Verstehe ich nicht. Die Frage nach dem Ob und dem Dass lässt sich ohne Aufwand mit ja beantworten.

Ich hatte hier eher im Sinn, dass die Daten von irgendwoher kommen und nicht als Text im Code stehen. In dem Fall mache ich mir keine Gedanken, ob da typografische Anführungszeichen drin stehen oder irgendwas ganz anderes. Wenn die Aufgabe lautet, diese Daten in HTML einzufügen, dann kommt da ein htmlspecialchar() zu Einsatz. Oder mysqli_real_escape_string() für (My)SQL-Statements, oder was auch immer der Kontext verlangt. Es hilft in solchen Fällen kein bisschen, sich Gedanken um Escaping-Erleichterungen zu machen.

Natürlich löst die Verwendung von „“ (“”) nicht das Problem des Escapens von <, > und &.
Aber das des Escapens von ". Was besonders problematisch ist, weil " den Quelltext besonders unübersichtlich macht, da es – im Gegensatz zu <, > u.(a.) Klammern – sowohl als öffnendes als auch als schließendes Zeichen verwendet wird.

Du behandelst hier den einen Fall, dass du das Zeug direkt selbst in zum Beispiel ein HTML-Template oder ein String-Literal schreibst. Das war aber auch grad nicht das Problem des OP. Wenn du einen andersgelagerten Fall diskutieren wolltest, solltest du das dazusagen.

Dass dann nicht escapet werden muss, ist ein äußerst nützlicher Nebeneffekt.

Nur für den Fall, dass du die Anführungszeichen zu Fuß schreibst. Für die Verarbeitung von unbekannten Daten ist es irrelevant, ob du solche drin hast oder nicht. Es müssen für alle Sonderzeichen eines bestimmten Kontextes geeignete Maßnahmen ergriffen werden.

dedlfix.

[Gunnar Bittersmann]

@@dedlfix:

nuqneH

Du behandelst hier den einen Fall, dass du das Zeug direkt selbst in zum Beispiel ein HTML-Template oder ein String-Literal schreibst. Das war aber auch grad nicht das Problem des OP. Wenn du einen andersgelagerten Fall diskutieren wolltest, solltest du das dazusagen.

Um das Problem des OP ging es in https://forum.selfhtml.org/?t=219102&m=1511863 schon nicht mehr, sondern um deinen Wiki-Artikel.

Und ja, mir ging es um selbst erstellte Textinhalte. Und ja, das hätte ich dazusagen sollen.

Nur für den Fall, dass du die Anführungszeichen zu Fuß schreibst. Für die Verarbeitung von unbekannten Daten ist es irrelevant, ob du solche drin hast oder nicht. Es müssen für alle Sonderzeichen eines bestimmten Kontextes geeignete Maßnahmen ergriffen werden.

Und ja, für nutzergenerierte (o.a. fremde) Inhalte ist meine Aussage „Dabei gibt er den falschen Rat, " zu escapen. Richtig wäre der Rat, richtige Anführungszeichen (de: „“, en: “”) zu verwenden“ zugegebenermaßen unsinnig.

Wenn die " erstmal da sind, kriegt man sie kaum wieder weg. (Automtische Umwandlung in „“ bzw. “” ist problematisch.) Und ja, dann müssen sie natürlich beim Kontextwechsel entsprechend escapet werden.

Qapla'

[dedlfix]

Tach!

Wenn die " erstmal da sind, kriegt man sie kaum wieder weg. (Automtische Umwandlung in „“ bzw. “” ist problematisch.)

Sowas ist dann besonders lustig/ärgerlich, wenn das zum Beispiel eine Blog-Software macht, um der Welt was gutes zu tun, und dabei auch vor Code nicht haltmacht, bei dem die Syntax " und keine typografischen vorschreibt.

dedlfix.

[ChrisB]

Hi,

Es handelt sich um einen Artikel zu einem technischen Thema, und du meinst unbedingt etwas völlig themenfremdes hinein bringen zu müssen

Ja, genau das meine ich mit „Wie sollten die [Einsteiger] sonst auf Gebiete stoßen, die außerhalb ihrer bisherigen Welt liegen?“

Vielleicht haben sie auch noch nie Kürbiskernsuppe gekocht, Skat gespielt oder Afrika bereist – bau das also besser schnell in den Artikel ein, sonst stoßen Einsteiger nie darauf …

Wenn du Typographie tatsächlich für völlig unnützen Quatsch hältst

Habe ich nicht gesagt. Jetzt verdrehst du mal wieder Sachverhalte, nur damit Gunnar recht behalten kann.

Außerdem gehört die Vermeidung von Escapes durchaus zum Thema Escapes dazu.

Und Klugscheißen um des Klugscheißens Willen gehört zum Gunnar.

Das Escapen von " *kannst* du nicht vermeiden, wenn der Kontext es erfordert.

Dass die Verwendung von " im Inhalt ggf. nicht angebracht sein mag – vollkommen andere Baustelle.

MfG ChrisB

[Richie]

DANKE für eure Inputs!

Tatsächlich hat sich der Fehler beim Umwandeln der $_POST['meintext'] eingeschlichen... war nur ein simpler Typo wo ich ihn nicht vermutet hätte ;-)

[Gunnar Bittersmann]

@@Richie:

nuqneH

<textarea name="meintext[<?php echo $id ?>]"><?php echo $meintext ?></textarea>

So weit so gut.

Nein, gar nicht gut.

Wo kommt die Werte von $id und $meintexther? Ja, aus der DB. Ich meine ursprünglich.

Kannst du 100%ig sicher sein, dass da nichts Böses drinstehen kann?

Prinzipiell sind alle Werte außerhalb deiner Kontrolle als böse anzusehen. Und müssen deshalb kontextgerecht behandelt werden. (Das ist, was Robert R. versuchte zu sagen, aber nicht konnte.)

In diesem Fall heißt das: Ein Wert wird in den HTML-Kontext gebracht und muss unschädlich gemacht werden. Insbesondere < und >, damit kein fremder JavaScript-Code eingeschleust werden kann. Dazu dient die Funktion [link:http://php.net/manual/function.htmlspecialchars.php@title=htmlspecialchars()].

Es muss heißen:
<textarea name="meintext[<?php [code lang=php]echo htmlspecialchars($id); ?>]"><?php echo htmlspecialchars($meintext); ?></textarea>
[/code]

Qapla'