v1.0.2: Strophe.serialize() doubles escaping

[Michael Weibel]

Hi,

In the recent version of strophe, a message sent via the muc-plugin gets escaped twice.

e.g.

<3 gets escaped to &lt;3 instead of <3 as before.

This happens also for apostrophes, quotes etc.

I think this is a bug, but don't know if the MUC-Plugin doesn't handle it correctly or if it's something inside the strophe-core (I think it's in strophe..)

Cheers,
Michael

[Michael Weibel]

changing the following on line 1163 does work for me (in Strophe.serialize())

before:

                  case Strophe.ElementType.TEXT:
                    // text element to escape values
                    result += Strophe.xmlescape(child.nodeValue); // <--- LINE 1163
                    break;

after:

                  case Strophe.ElementType.TEXT:
                    // text element to escape values
                    result += child.nodeValue; // <--- LINE 1163
                    break;

But, as this was a recent change to the code, I don't know if this causes other problems... (in commit #f7378de440cf9c3c671b025688ce80381ceed257)

[Lee Boynton]

I notice the same problem, and I'm not using the MUC plugin. It seems that it is being escaped in Strophe.xmlTextNode() and Strophe.serialize().

[kenstir]

+1

This patch fixed the issue for me:

Index: xmpp/strophe.js

--- xmpp/strophe.js (revision 4337)
+++ xmpp/strophe.js (revision 4338)
@@ -1160,7 +1160,9 @@ Strophe = {
break;
case Strophe.ElementType.TEXT:
// text element to escape values

•                result += Strophe.xmlescape(child.nodeValue);
  

•                //[e-mail]: eliminate double-escape which also hap
  

  pens in xmlTextNode()

•                //result += Strophe.xmlescape(child.nodeValue);
  

•                result += child.nodeValue;
               break;
             case Strophe.ElementType.CDATA:
               // cdata section so don't escape values
  

[Matthew Wild]

This is the wrong fix. The serializer is fine, the problem is that the text is being escaped as it's inserted into the DOM, which is wrong. The escaping should happen only when it's necessary to convert the XML to a string for sending on the wire, etc. I've submitted this pull request with a tiny commit to remove the extra escaping: #59

[Astro]

Pull request #59 was closed.

I think however this issue was wrong. Text content should not contain tags. Handling XML as strings can have security implications.

[kenstir]

You really don't believe that inserting "<3" on one end and receiving "<3" on the other end is an issue?

[Astro]

No, you've got me wrong, and I probably got this issue wrong. (Which does not matter as the pull request had been merged already.)

What goes in as text should be escaped in the XML serialization. What is being parsed shall be unescaped in text node content, however again escaped after a serialization round-trip.

[Jack Moffitt]

I think this is a bug, but don't know if the MUC-Plugin doesn't handle it correctly or if it's something inside the strophe-core (I think it's in strophe..)

I believe this was probably related to a bug that was fixed. Does this
still happen?

jack.

[Michael Weibel]

I didn't test that yet, need to do that asap. But I think the other fix will do it.

[Matthew Wild]

This issue should be fixed since this was merged: #59

[Sonny Bhatia]

Apparently this continues to happen for kick messages, and possibly for part messages. I suspect it's due to the same reasons as above.