search

mwood77 / pf2opn

An in-browser pfsense to opnsense converter.
https://www.pf2opn.com
Other
88 stars 7 forks source link

CDATA markers not handled #20

Closed madscientist159 closed 5 months ago

madscientist159 commented 5 months ago

Older versions of pfSense tend to wrap all user strings in CDATA markers, as follows:

      <descr>
        <![CDATA[User provided text goes here]]>
      </descr>

OPNsense doesn't know what to do with these and inserts a bunch of unwanted newlines and spaces around the user text on restore.

mwood77 commented 5 months ago

Should the CDATA fields be handled like this? I assumed they represented interpolated data, but it looks like they're more along the lines of "comments that will be included in the XML."

# before

<descr>
      <![CDATA[User provided text goes here]]>
</descr>
# after

<descr>
      User provided text goes here
</descr>
madscientist159 commented 5 months ago

They should look more like this after. OPNsense is sensitive to newlines, pfSense apparantly wasn't.

# after

<descr>User provided text goes here</descr>

Also, the CDATA fields show up other places, including a couple of fields that are parsed (non-comment) data. They all need to be scrubbed out along with their associated newlines as above.

To make things more interesting, AFAIK a CDATA field could have newlines within the CDATA tags, and those newlines need to be preserved. :wink:

mwood77 commented 5 months ago

CDATA tags have now been removed, and I've added the option to download a configuration with "no formatting." When it comes to recursive string interpolation, I don't see myself getting to that anytime in the near future.

Id be surprised if opnsense cannot handle either type of import, as both are valid XML.