New Proxy Editor (15.07) will not allow XML encoding - keeps converting back to characters not allowed

Not applicable

When I am trying to define some RegEx expressions in the RegularExpressionProtection policy (my SQL Injection protection) using Apigee Edge 15.07, I need to include "<" and ">" in the expression. Since I am defining it inside XML, I can't use the symbols as-is, and am trying to use "<" and ">" instead. HOWEVER, apigee keeps converting them back to "<>", and then will not let me save the policy as the symbols are invalid for XML.

If I switch to the old version of the editor (15.04), I can save just fine, but the new version (15.07) seems to be running a script (I am using Chrome) to try to convert my XML encoding back, and when it does, it complains about lack of encoding. Is there a bug in 15.07 dealing with XML characters in XML Policy editor???

Solved Solved
1 4 255
1 ACCEPTED SOLUTION

Not applicable

So I know I'm late to this, but one workaround (not ideal) is to double up your xml-encoding.

So to take from the server-side include Reg Ex protection policy pattern:

&lt;!--\s*&lt;!--(include|exec|echo|config|printenv)\s+.*

Would need to be put into the editor as:

&amp;lt;!--\s*&amp;lt;!--(include|exec|echo|config|printenv)\s+.*

And then it will save as your intended encoding (the first one).

Like I said, it's not ideal, but if you have to work with the UI editor then it is a workaround to inform your proxy developers about.

-----------

A coworker pointed out that another option is to use the old editor briefly to add the xml-encoded text, save, then return to the new editor.

View solution in original post

4 REPLIES 4

Dear @Boris , Thank you for highlighting same & valuable feedback. We will let our Engineering team know about same. We will keep you posted on same. Thank you

Dear @Boris ,

Can you share sample policy xml if possible ?

@Anil Sagar

I'm not Boris, but, ...Just use a "GREATER THAN" comparison operator in a Condition element. Normally it is serialized as &gt; Eg,

<Step>
  <Name>RF-TimeExpired</Name>
  <Condition>days_active &gt; 30</Condition>
</Step>

Type such a condition into the "new" proxy editor. Save the revision. Click away, to the list of API proxies. Again click into the apiproxy you just modified. Open the default.xml that contains the condition. you will see that it gets de-serialized as >.

<Step>
  <Name>RF-TimeExpired</Name>
  <Condition>days_active > 30</Condition>
</Step>

This appears to be tolerated in the proxy editor. Also if you then query the proxy, as with

curl -i -n -H accept:text/xml \
   https://api.enterprise.apigee.com/v1/o/ORGNAME/apis/APINAME/revisions/N/proxies/default

...then you get the xml-safe version of the GREATER THAN operator.

Therefore I think this is just a UI anomaly. It appears that the UI for the new proxy editor is un-escaping the XML Text within a condition, before display.

Not applicable

So I know I'm late to this, but one workaround (not ideal) is to double up your xml-encoding.

So to take from the server-side include Reg Ex protection policy pattern:

&lt;!--\s*&lt;!--(include|exec|echo|config|printenv)\s+.*

Would need to be put into the editor as:

&amp;lt;!--\s*&amp;lt;!--(include|exec|echo|config|printenv)\s+.*

And then it will save as your intended encoding (the first one).

Like I said, it's not ideal, but if you have to work with the UI editor then it is a workaround to inform your proxy developers about.

-----------

A coworker pointed out that another option is to use the old editor briefly to add the xml-encoded text, save, then return to the new editor.