Bug report - Workflow extension - escape characters : < > &&

[NBP]

Hello,

We created a workflow extension with one TEXTAREA field. If we use this workflow and configure it writing characters `<` or `>` or `&` in the textaera field, the request received by our server from HubSpot contains the text with these characters "HTML escaped" : &lt; &gt; and &amp;

Is it a bug ?

Thank you
Regards

[NBP]

Hello @IsaacTakushi ,

OK thanks for your answer.

Can you provide the list of all affected characters (only `<`, `>` and  `&` ?) ?

So that we can code a temporary hack for it.

Thank you.

[IsaacTakushi]

Hello, @NBP.

Correct. Only the `<`, `>`, and `&` appear to be affected. In testing the following payload:

AaBbCcDdEeFfGgHhIiJjKkLlMmNnOoPpQqRrSsTtUuVvWwXxYyZz
1234567890
~`!@#£€$¢¥§%º^&*()-_+={}[]|\/:;"'<>,.?

The resulting JSON included:

AaBbCcDdEeFfGgHhIiJjKkLlMmNnOoPpQqRrSsTtUuVvWwXxYyZz
1234567890
~`!@#£€$¢¥§%º^&*()-_+={}[]|\\/:;\"'<>,.? 

[dennisedson]

Heyo @NBP 

Throwing a few Community folk at this who may be able to help

@biahn , @AJT , @pbmartin , @Kevin-C , @juliardi and @kimnguyen 👋

Any of you able to confirm this?

[NBP]

Hello,

Can you reproduce the problem?

Thank you.

[IsaacTakushi]

Hi, @NBP.

I have been able to reproduce the behavior with one of my own workflow extensions.

As an example, a line entered as <p>This is paragraph HTML content & features an ampersand.</p> in the workflow editor was received as &lt;p&gt;This is paragraph HTML content &amp; features an ampersand.&lt;/p&gt; within the JSON payload.

I still need to confirm whether this is expected or not. I look forward to getting to the bottom of this. Thanks for your patience.

[NBP]

Hello @IsaacTakushi and @dennisedson ,

An other simple example : "Text -> Text" in the workflow editor was received as "Text -&gt; Text" within the JSON.

Any news on the subject?

Thank you.

[IsaacTakushi]

Hi, @NBP.

Thank you for the additional example of the < character being escaped.

We do not believe this is expected behavior, so thank you for reporting. We have begun tracking this internally.

With that said, since this is the first report of the behavior and removing the escaping will require estimating how many apps such a change could affect (e.g. other integrations which may already be unescaping these symbols), I do not expect this to be resolved in the immediate future. I will keep this thread open and post relevant updates as they arise. Thank you for your understanding.