Inhalt Textarea mittels <input type="hidden"... übergeben

[Jeena Paradies]

Hallo,

Ich habe eine textarea deren Inhalt per post an ein Vorschau-Script weitergeleitet wird. Von dort aus soll dieser dann an ein weiteres Script - welches einen Newsletter verschickt - geleitet werden.

Bisher habe ich es dann auf der Vorschau Seite mittels eines hidden input Feldes und eines Passwortfeldes weitergeleitet. Doch jetzt habe ich gemerkt dass wenn man in die Textarea HTML Code eingibt, dieser ja in value="" drin ist und gegebenenfalls teilweise zum vorschein kommt. Ich will die E-Mail, die dann verschickt wird aber als text/plain verschicken. Ich weiß dass man mit php htmlspecialchars() alles umwandeln kann, so dass nichts zu sehen ist, doch in der text/plain E-Mail soll ja alles so angezeigt werden wie man es in die Textarea eingegeben hat, auch wenn es html Code ist.

Das bisher gemachte zum besseren Verständniss hier: http://jeenaparadies.clever-webspace.de/koorbash/newsletter-schreiben.php

Wie schaffe ich es jetzt alles zu übergeben, ohne dass man es sieht, auch wenn dort html Code drinn ist, und dabei dann in der E-Mail alles so zu lassen wie es eingegeben wurde?

Grüße
Jeena Paradies

[Harry]

Holladiewaldfee,

codiere den Inhalt der Textarea mit Hilfe von htmlspecialchars(), bevor Du ihn in das hidden-Feld schreibst.

Ciao,

Harry

[Jeena Paradies]

Hallo,

codiere den Inhalt der Textarea mit Hilfe von htmlspecialchars(), bevor Du ihn in das hidden-Feld schreibst.

Das Problem dabei ist, dass dann in der text/plain E-Mail statt

<a href="#">Textlink</a>

Das drinn stehen wird:
<a href="#">Textlink</a>
Was ja nicht im Sinne dessen ist, der Quellcode verschicken will. Und ich finde irgendwie keine Möglichkeit das wieder rückgängig zu machen.

Grüße
Jeena Paradies

[Sven Rautenberg]

Moin!

codiere den Inhalt der Textarea mit Hilfe von htmlspecialchars(), bevor Du ihn in das hidden-Feld schreibst.
Das Problem dabei ist, dass dann in der text/plain E-Mail statt

<a href="#">Textlink</a>

Das drinn stehen wird:
<a href="#">Textlink</a>

Punkt 1: Hast du es ausprobiert? Nein! Du wirst dich erinnern, dass man in href-Attributen das &-Zeichen als & schreiben muß, weil sonst der Validator meckert. Der Server aber kriegt, wenn der Link geklickt wird, kein & zu sehen, sondern nur das & - ergo: Der Browser sieht die Entity-Codierung im Attribut und dekodiert sie, bevor er die Seite anzeigt. Dasselbe wird auch deinem Value-Attribut im Hidden-Feld passieren.

Punkt 2: In einer Text/plain-Email hat HTML-Code sowieso nichts zu suchen. Oder ich verstehe dich gerade absolut falsch.

Was ja nicht im Sinne dessen ist, der Quellcode verschicken will. Und ich finde irgendwie keine Möglichkeit das wieder rückgängig zu machen.

Testen, probieren, staunen. :)

Ich sehe bei der Hidden-Feld-Methode eigentlich nur ein Problem: Was ist mit den Zeilenumbrüchen? Die werden nicht codiert und könnten verloren gehen - sie sehen zumindest ekelhaft aus im Quelltext. Deshalb ist es besser, den Textstring base64 zu codieren und dann im endgültigen Auswerteskript wieder zu dekodieren.

- Sven Rautenberg

[Jeena Paradies]

Hallo,

Punkt 1: Hast du es ausprobiert? Nein! Du wirst dich erinnern, dass man in href-Attributen das &-Zeichen als & schreiben muß, weil sonst der Validator meckert. Der Server aber kriegt, wenn der Link geklickt wird, kein & zu sehen, sondern nur das & - ergo: Der Browser sieht die Entity-Codierung im Attribut und dekodiert sie, bevor er die Seite anzeigt. Dasselbe wird auch deinem Value-Attribut im Hidden-Feld passieren.

Mensch ich habe mich so darauf versteift irgendwas zum Dekodieren zu finden, dass ich an diese Möglichkeit nicht einmal gedacht hab, so dass ich das gar nicht ausprobiert habe.

Punkt 2: In einer Text/plain-Email hat HTML-Code sowieso nichts zu suchen. Oder ich verstehe dich gerade absolut falsch.

Naja wenn der Newsletterschreiberling so was schreiben will:
--------------------------------
Hallo meine Anhänger,

Wisst ihr wie man in HTML einen Link macht? Nein, dann will ich euch das vorführen:
<a href="seite.htm">Textlink</a>
Jetzt wisst ihr es.
--------------------------------
Dann muss der Quellcode nun mal rein. Ich weiß das passiert nicht alzu oft aber falls doch soll das Script schon darauf vorbereitet sein.

Testen, probieren, staunen. :)

Jo hab ich jetzt gemacht, und tatsächlich gestaunt :-) Danke.

Ich sehe bei der Hidden-Feld-Methode eigentlich nur ein Problem: Was ist mit den Zeilenumbrüchen? Die werden nicht codiert und könnten verloren gehen - sie sehen zumindest ekelhaft aus im Quelltext. Deshalb ist es besser, den Textstring base64 zu codieren und dann im endgültigen Auswerteskript wieder zu dekodieren.

Hm base64 was ist dass denn nun? ...Such such such... Hm ach so, ja stimmt so was kannte ich bisher noch gar nicht. Muss mich damit wohl mal auseinander setzen.

Table 1: The Base64 Alphabet

Value Encoding  Value Encoding  Value Encoding  Value Encoding
         0 A            17 R            34 i            51 z
         1 B            18 S            35 j            52 0
         2 C            19 T            36 k            53 1
         3 D            20 U            37 l            54 2
         4 E            21 V            38 m            55 3
         5 F            22 W            39 n            56 4
         6 G            23 X            40 o            57 5
         7 H            24 Y            41 p            58 6
         8 I            25 Z            42 q            59 7
         9 J            26 a            43 r            60 8
        10 K            27 b            44 s            61 9
        11 L            28 c            45 t            62 +
        12 M            29 d            46 u            63 /
        13 N            30 e            47 v
        14 O            31 f            48 w         (pad) =
        15 P            32 g            49 x
        16 Q            33 h            50 y

Grüße
Jeena Paradies

[MudGuard]

Hi,

Ich habe eine textarea deren Inhalt per post an ein Vorschau-Script weitergeleitet wird. Von dort aus soll dieser dann an ein weiteres Script - welches einen Newsletter verschickt - geleitet werden.

Bisher habe ich es dann auf der Vorschau Seite mittels eines hidden input Feldes und eines Passwortfeldes weitergeleitet.

Sinn der Vorschau ist doch, daß man ggf. Fehler noch korrigieren kann - also wäre es doch wesentlich sinnvoller, dem User den Text nochmal in einer textarea zur Korrektur vorzulegen.
Ein hidden-Feld brauchst Du dann doch gar nicht...

cu,
Andreas

[Tom]

Hello,

Sinn der Vorschau ist doch, daß man ggf. Fehler noch korrigieren kann - also wäre es doch wesentlich sinnvoller, dem User den Text nochmal in einer textarea zur Korrektur vorzulegen.
Ein hidden-Feld brauchst Du dann doch gar nicht...

Das ist nicht ergonomisch. Eine Vorschau sollte so aussehen, wie der Text nachher auch angezeigt wird. Siehe hierzu die Vorschaufunktion des Forums. Links, Tags und BB-Codes sollten schon angezeigt werden.

Anderenfalls hätte man die Vorschau gar nicht nötig, sondern nur den schlauen[tm] Satz: "Schauen Sie sich Ihre Eingaben nochmal genau an, bevor Sie auf 'abschicken' clicken" *haha*

Grüße

Tom

[Harry]

Holladiewaldfee,

Das ist nicht ergonomisch. Eine Vorschau sollte so aussehen, wie der Text nachher auch angezeigt wird. Siehe hierzu die Vorschaufunktion des Forums. Links, Tags und BB-Codes sollten schon angezeigt werden.

Du hast das falsch verstanden.
Hier im Forum hast Du ja auch die Möglichkeit, Deinen Text direkt unter der Vorschau nochmal zu editieren. Jeena hat aber ein hidden-Feld, so daß man den Text eben _nicht_ editieren kann. Insofern hat Andreas durchaus recht.

Ciao,

Harry

[Tom]

Hello,

Du hast das falsch verstanden.

Nein, ich habe das richtig verstanden. Ich habe nur gerade andere Formulardimensionen vor Augen gehabt, als diese süßen fünf Feldchen hier. ;-) -> siehe Antwort an Andreas

Hier im Forum hast Du ja auch die Möglichkeit, Deinen Text direkt unter der Vorschau nochmal zu editieren. Jeena hat aber ein hidden-Feld, so daß man den Text eben _nicht_ editieren kann. Insofern hat Andreas durchaus recht.

Das ist bei der Anzahl von Feldern ja auch gut so.

Grüße

Tom

[Jeena Paradies]

Hallo,

als diese süßen fünf Feldchen hier. ;-) -> siehe Antwort an Andreas

"Süße fünf Feldchen" *schmoll* Die haben es ganz schön in sich, wenn man erst am Anfang seiner PHP Kariere ist ;-)

Grüße
Jeena Paradies

[Tom]

Hello,

als diese süßen fünf Feldchen hier. ;-) -> siehe Antwort an Andreas
"Süße fünf Feldchen" *schmoll* Die haben es ganz schön in sich, wenn man erst am Anfang seiner PHP Kariere ist ;-)

Ja, entschuldige bitte. Kannmich noch gut an meine ersten "süßen fünf Feldchen" erinnern. Nix hat geklappt (damals war gerade PHP3 rausgekommen). Überall tauchten Backslashes auf und die wurden immer mehr, und dann reagierte der Browser so merkwürdig, wen einer in die textarea den Text "</textarea>" schrieb und überall waren Sicherheitslücken und als ich dann mit MySQL anfingen, hat einer meiner Profis mit mit einer Eingabe im Formularfeld (demonstrationshalber) die ganze DB verschwinden lassen.

Danach habe ich erstmal viel gelesen...

Grüße

Tom

[Jeena Paradies]

Hallo,

Ja, entschuldige bitte. Kannmich noch gut an meine ersten "süßen fünf Feldchen" erinnern. Nix hat geklappt (damals war gerade PHP3 rausgekommen). Überall tauchten Backslashes auf und die wurden immer mehr, und dann reagierte der Browser so merkwürdig, wen einer in die textarea den Text "</textarea>" schrieb und überall waren Sicherheitslücken und als ich dann mit MySQL anfingen, hat einer meiner Profis mit mit einer Eingabe im Formularfeld (demonstrationshalber) die ganze DB verschwinden lassen.

Ach ja dann weißt du ja wie es mir geht :-)

Danach habe ich erstmal viel gelesen...

Das tue ich auch, jeden Tag ist zwar anstrengend, aber auch interresant. Und jetzt mache ich das gleich wieder :-)

Grüße
Jeena Paradies

[MudGuard]

Hi,

Sinn der Vorschau ist doch, daß man ggf. Fehler noch korrigieren kann - also wäre es doch wesentlich sinnvoller, dem User den Text nochmal in einer textarea zur Korrektur vorzulegen.
Ein hidden-Feld brauchst Du dann doch gar nicht...
Das ist nicht ergonomisch.

Doch, ist es. Wesentlich ergonomischer als das hidden-feld (zusätzlich zur Anzeige).

Eine Vorschau sollte so aussehen, wie der Text nachher auch angezeigt wird.

Klar - aber ZUSÄTZLICH sollte eben auch die textarea zum Korrigieren da sein.
Das ist wesentlich praktischer als das hidden-feld...

cu,
Andreas

[Tom]

Hello,

Klar - aber ZUSÄTZLICH sollte eben auch die textarea zum Korrigieren da sein.
Das ist wesentlich praktischer als das hidden-feld...

Das hängt sicher von der Größe des Formulars ab. Es muss ja nicht nur eine Textarea enthalten sein. Es könnte sich das Gesamtbild auch erst am Schluss ergeben (nach mehreren Seiten Erfassung) und man hat dann nochmal die Möglichkeit, zu einzelnen Korrekturen zurückzuspringen.

Wenn es nur so wenige Felder sind, wie hier zum Besipiel, finde ich Deinen Vorschlag aber auch gut.

Grüße

Tom

[Tom]

Hello,

da baust Du dir als erstes mal ein vernünftiges "Affenformular", dass alles Zustände beherrscht.

Die Methode mit der Aufteilung in verschiedene Formualare führt sehr schnell ins Pflegedesaster.

Für die Werteweitergabe gibt es dann eigentlich nur zwei Ansätze:
1. Die Werte werden nur bei der Erfassung validiert und sind
wichtig/geheim: Sessions
Vorteile:  Verminderter Datenverkehr, sofortige endgültige
           Validierung möglich
Nachteile: Benutzer müssen Cookies eingeschaltet haben oder sich
           anmelden. (mMn sind Sessions ohne Cookies Müll)

2. Die Werte stammen sowieso vom User selber, warum sollte esr sie also nicht mehr sehen dürfen? Es sind keine großen Datenmengen (> 5kb entsprechend ca. < 1s Ladezeit, dam muss man eben mal rechnen). Die Werte werden in der letzten Zustandsstufe vor der Verarbeitung nochmals validiert.
Vorteile:  Keine Anmeldung nötig, funktioniert mit einfachstem
           HTML am Frontend, keine Cookies notwendig
Nachteile: doppelte Validierung notwendig, erhöhter Datenverkehr
           (was aber angesichts der Bilderseiten von heute
           bestimmt zu vernachlässingen ist). Bilder können erst in
           der letzten Seite dazugeladen werden, da man diese nicht
           "durchschleifen" sollte.

Umgang mit Variablen bei Mthode 2:

Erfassungsformular

Verarbeitungsscript erkennt den Zustand (Stufe der Verarbeitung)
Daten werden übernommen
Daten werden serialisiert (Array)
Daten werden base64-codiert
Codierte Daten in hidden-Feld verpacken
Script -> Erfassungsformular
Erfassungsformular -> Script
Daten base64-decodieren
Daten unserialisieren (Array wiederherstellen)
neue Daten übernehmen und prüfen
dem Array hinzufügen

serialisieren
codieren
hidden Feld
nächster Verarbeitungsschritt

usw.

So kann man eine ganze Verarbeitungskette aufbauen.

Das einzig komplizierte ist die Erstinitialisierung. Man muss sich einen Mechanismus schaffen, der erkennt, ob schon ein gültiges Datenarray um Formular versteckt ist. Wenn nein, wird es angelegt und der Status auf kleinsten Wert gesetzt, das Form initialisiert und das erste Mal an den Client ausgeliefert.

I hoff, Du hoast mi

Grüße

Tom

[Jeena Paradies]

Hallo,

da baust Du dir als erstes mal ein vernünftiges "Affenformular", dass alles Zustände beherrscht.

Huch was ist denn ein "Affenformular"?

Die Methode mit der Aufteilung in verschiedene Formualare führt sehr schnell ins Pflegedesaster.

Ich glaube bei meinem Teil funktioniert es noch ohne es aufzuteilen. Aber wenn es so weit ist, dann werde ich deinen Beitrag im Archiv finden, und mich durchbeisen. Jetzt verstehe ich noch zuwenig von den ganzen Sachen, die du hier aufgezählt hast, aber das wird mit der Zeit.

Grüße
Jeena Paradies

[Harry]

Holladiewaldfee,

da baust Du dir als erstes mal ein vernünftiges "Affenformular", dass alles Zustände beherrscht.
Huch was ist denn ein "Affenformular"?

Ein Affenformular ist ein Formular, bei dem 1.000.000 Affen 1.000.000 mal auf "Absenden" klicken können, ohne Schaden anzurichten ;) Sprich: Du weist den Benutzer nach dem Abschicken auf fehlende Angaben hin und bietest ihm das Formular so wie er es ausgefüllt hat auf derselben Seite zum Korrigieren an.

Ciao,

Harry

[Jeena Paradies]

Hallo,

Ein Affenformular ist ein Formular, bei dem 1.000.000 Affen 1.000.000 mal auf "Absenden" klicken können, ohne Schaden anzurichten ;) Sprich: Du weist den Benutzer nach dem Abschicken auf fehlende Angaben hin und bietest ihm das Formular so wie er es ausgefüllt hat auf derselben Seite zum Korrigieren an.

Ach so, also schon so wie ich das ungefär gemacht hab auch wenn es noch nicht fertig ist.

Grüße
Jeena Paradies