You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on May 20, 2024. It is now read-only.
If a location contains the & character in its description, such as lots of apples & pears, this will translate to the following GPX waypoint:
<wptlat="1.2345"lon="6.789">
<name>Lovely place</name>
<desc>lots of apples & pears</desc>
<type>places</type>
</wpt>
This is invalid XML since the & character should be escaped: we should have <desc>lots of apples & pears</desc> instead.
This is caused by the jstoxml package used for the export, which does not handle escaping by default (?!). Apparently you can pass a configuration object to specify characters to replace but that's cumbersome. It should escape things by default, as this is a classic vulnerability.
For me that's a red flag - another package should be used instead. I have opened an issue on their side: davidcalhoun/jstoxml#41
The text was updated successfully, but these errors were encountered:
Thanks! Yes, I remember being not so content with any of the XML libraries I encountered. Some of the more complete ones were very large, whereas we have very minimal requirements.
One alternative could be to just create the XML as a string... escaping the string content manually. Maybe it's just about 4 lines of code :)
It looks like it will get fixed soon in davidcalhoun/jstoxml#41, but the test I added should break on the upgrade to let us know we can remove my escaping code :)
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
If a location contains the
&
character in its description, such aslots of apples & pears
, this will translate to the following GPX waypoint:This is invalid XML since the
&
character should be escaped: we should have<desc>lots of apples & pears</desc>
instead.This is caused by the
jstoxml
package used for the export, which does not handle escaping by default (?!). Apparently you can pass a configuration object to specify characters to replace but that's cumbersome. It should escape things by default, as this is a classic vulnerability.For me that's a red flag - another package should be used instead. I have opened an issue on their side: davidcalhoun/jstoxml#41
The text was updated successfully, but these errors were encountered: