Deus Figendi: dynamisches SVG speichern lassen

Beitrag lesen

Vielen Dank für deine Antwort.

XMLSerializer kennen verschiedene Browser.

Nach kurzer Recherche habe ich den Eindruck: Alle relevanten Browser. Cool, dankeschön!

Im Prinzip ja, nur solltest du vorher noch http://de.selfhtml.org/javascript/objekte/document.htm#open@title=open und nachher http://de.selfhtml.org/javascript/objekte/document.htm#close@title=close aufrufen.

Das war das erste PopUp meines Lebens :D

Wenn du window.open mit nur zwei Parametern öffnest, sollte Chrome ein einfachen Tab öffnen.

Na macht er aber nicht... ist aber Wurst, man kann da ja irgendwas dran einstellen, muss ich mich mal reinfuchsen.

Server und zurück...
Auch sehr gut und vielleicht sogar besser, weil document.open/write/close von HTML ausgeht.
Indem du ein POST-Formular baust und es via JavaScript (oder einen herkömmlichen Button) absendest. Ob das in SVG geht, weiß ich nicht.

Während ich deine Antwort las kam mir die Idee ob ich nicht einfach das XHTML-Formular in einem neuen Fenster/Tab erstellen kann/sollte und dieses dann absende. Also quasi beide Varianten mischen, damit sollt ich imho alle Probleme erschlagen, das Zielfenster bekommt wie es deiner Antwort nach erwartet HTML, ein Zielfenster für die Antwort existiert bereits, ein POST-Request wird "ordnungsgemäß" erstellt.
Ich mag diese Idee...

Das ist möglicherweise reflected XSS. Du solltest prüfen, ob das wirklich korrektes SVG ist, sowie Scripte filter. Das wird u.U. schwierig.

Ja, validieren kann ich das nicht. Scripte rausfiltern könnte aber klappen. Ist ja im Grunde schon erledigt wenn ich die Zeichenfolge <script (caseinsensitive) tilge. Dann fällt unter Umständen zwar ungültiger Code raus und das JS (oder was auch immer) steht irgendwie schief im Dokument. Aber das Problem tritt ja nur bei Angriffen auf und nicht versehentlich. Und wenn ein Angriff sichtbar aber ineffektiv ist ist es auch okay.
Was könnte noch gefährlich sein (denke an Flash)? <object> <embed> <frame> <iframe> <frameset> und eben <script>. Noch irgendwas, was Browser in SVG-Dokumenten in gefährlicher Art und Weise "fehlinterprettieren" könnten? (Sicherheitslücken die z.B. Bildformate betreffen kann ich nicht bekämpfen)

Oder du verlagerst das auf eine separate Domain, wo es keine Cookie-Authentifizierung oder sonst irgendwelche privaten Daten abzugreifen gibt.

Fällt raus, geht nicht.

Erscheint mir sehr aufwendig, aber wenn es sein muss... was muss ich da beim Escaping beachten?

Nichts, das erledigt der Browser.

Wenn ich was tue? Oder ist das egal?

Fenster.document.write('<textarea name="svg_string">'+svg_string+'</textarea>');  
//oder  
Fenster.document.write('<input type="hidden" name="svg_string">'+svg_string+'</input>');  
//oder  
Fenster.document.getElementsByName("svg_string")[0].appendChild(document.newTextNode(svg_string));  
//oder  
Fenster.document.getElementsByName("svg_string")[0].firstChild.data= svg_string;

In welchen Fällen wird der Browser richtig escapen?

Wie gesagt: Vielen Dank für die Erkenntnisse bis hier her :)

--
sh:( fo:| ch:? rl:( br:& n4:& ie:{ mo:} va:) de:µ_de:] zu:) fl:( ss:| ls:[ js:(