New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

escaping xml / html in tables #878

Closed
legatoloco opened this Issue Feb 24, 2016 · 6 comments

Comments

Projects
None yet
2 participants
@legatoloco

legatoloco commented Feb 24, 2016

I have function that expects a content that looks like

{"xml":"<script><tag>content</tag></script>"}

(as a map)
when building the table for this, it looks like

| check | functionName; | !{xml:<script><tag>content</tag></script>} | output |
This breaks the wiki rendering due to the unescaped <script> element. the function receives a completely broken xml

| check | functionName; | !{xml:!-<script><tag>content</tag></script>-!} | output |
This breaks the function as the xml is never unescaped

I assume that one of !- or !< (which didn't do anything, ended up not interpreting the !< and considering it part of the text) is supposed to

  1. escape before rendering
  2. unescape when building parameters for the function

Which one should it be? and in all cases, I believe that both are broken.

@amolenaar

This comment has been minimized.

Show comment
Hide comment
@amolenaar

amolenaar Mar 4, 2016

Collaborator

This is kind of a nasty one. The Slim test system runs the HTML, not the wiki text. As a result, elements are passed on the way they are rendered in the HTML page.

Your assumption 1. is true: the !- operator just takes the contents of the "escaped" block and adds it to the page. Seems like '!<' has not done anything for quite a few years (I checked even back to 2012). I'll remove it from the reference guide.

About assumption 2, the map is sent to Slim as a html <table>. We might want to look into unescaping values inside that table (on the slim server side) when it's converted back to a Map. For that we'd need the same logic as being used in fitnesse.testsystems.slim.HtmlTable.

A short-term solution would be to unescape the contents in the fixture (call HtmlUtil.unescapeHtml()).

Collaborator

amolenaar commented Mar 4, 2016

This is kind of a nasty one. The Slim test system runs the HTML, not the wiki text. As a result, elements are passed on the way they are rendered in the HTML page.

Your assumption 1. is true: the !- operator just takes the contents of the "escaped" block and adds it to the page. Seems like '!<' has not done anything for quite a few years (I checked even back to 2012). I'll remove it from the reference guide.

About assumption 2, the map is sent to Slim as a html <table>. We might want to look into unescaping values inside that table (on the slim server side) when it's converted back to a Map. For that we'd need the same logic as being used in fitnesse.testsystems.slim.HtmlTable.

A short-term solution would be to unescape the contents in the fixture (call HtmlUtil.unescapeHtml()).

@amolenaar amolenaar added this to the Next release milestone Mar 4, 2016

@amolenaar

This comment has been minimized.

Show comment
Hide comment
@amolenaar

amolenaar Mar 8, 2016

Collaborator

I suppose this is what you're looking for:

screen shot 2016-03-08 at 22 25 44

The value printed by the SUT on stdout is:

Hash script is <script><b>bold</b></script>

Hence, the hash value is properly unescaped by FitNesse, just like a normal value passed to the SUT.

Collaborator

amolenaar commented Mar 8, 2016

I suppose this is what you're looking for:

screen shot 2016-03-08 at 22 25 44

The value printed by the SUT on stdout is:

Hash script is <script><b>bold</b></script>

Hence, the hash value is properly unescaped by FitNesse, just like a normal value passed to the SUT.

@legatoloco

This comment has been minimized.

Show comment
Hide comment
@legatoloco

legatoloco Mar 10, 2016

I guess so (unless i miss-understood your example)
This is the java function i'm using:
public String testmap(Map value){
return "something";
}
And these are the two options i have when passing the xml
image
which gets rendered in view mode as:
image
and in test mode as
image

If you debug the code, "value" is equal to:

  1. image
  2. image

Which shows that if I don't escape the xml myself, i get it escaped <script>
while if i do escape it first, it breaks the rendering in wiki (because now we do get the actual <script>, visible when you view-source) which breaks the html renderer of the browser, and generates the broken (but un-escaped code show in point 2)

Excuse the screenshot, but given that this is an encoding issue, i didn't want to add more confusion due to the github issue editor (which requires it's own escaping)

Related observation (but might require opening a different issue)
image

image

Check how the rendering fails differently in view vs edit mode.

Of course, not escaping has a better result when working with strings and not maps (like in the last two screenshots) as the content is sent correctly when not escaped, except that scripts are executes (the reason why the example i sent says "ablert" and not "alert"

legatoloco commented Mar 10, 2016

I guess so (unless i miss-understood your example)
This is the java function i'm using:
public String testmap(Map value){
return "something";
}
And these are the two options i have when passing the xml
image
which gets rendered in view mode as:
image
and in test mode as
image

If you debug the code, "value" is equal to:

  1. image
  2. image

Which shows that if I don't escape the xml myself, i get it escaped <script>
while if i do escape it first, it breaks the rendering in wiki (because now we do get the actual <script>, visible when you view-source) which breaks the html renderer of the browser, and generates the broken (but un-escaped code show in point 2)

Excuse the screenshot, but given that this is an encoding issue, i didn't want to add more confusion due to the github issue editor (which requires it's own escaping)

Related observation (but might require opening a different issue)
image

image

Check how the rendering fails differently in view vs edit mode.

Of course, not escaping has a better result when working with strings and not maps (like in the last two screenshots) as the content is sent correctly when not escaped, except that scripts are executes (the reason why the example i sent says "ablert" and not "alert"

@amolenaar

This comment has been minimized.

Show comment
Hide comment
@amolenaar

amolenaar Mar 10, 2016

Collaborator

And my table looks like this:

| script | hash fixture |
| send | !{script:<script><b>bold</b></script>} | as hash |
| check | hash | script | is | <script><b>bold</b></script> |

So in your example, that would translate to:

| check | testmap; | {code: <script><nested>ablert(1)</nested></script>} | <script><nested>ablert(1)</nested></script> |

Which yields the desired effect, right?

Collaborator

amolenaar commented Mar 10, 2016

And my table looks like this:

| script | hash fixture |
| send | !{script:<script><b>bold</b></script>} | as hash |
| check | hash | script | is | <script><b>bold</b></script> |

So in your example, that would translate to:

| check | testmap; | {code: <script><nested>ablert(1)</nested></script>} | <script><nested>ablert(1)</nested></script> |

Which yields the desired effect, right?

@amolenaar

This comment has been minimized.

Show comment
Hide comment
@amolenaar

amolenaar Mar 10, 2016

Collaborator

Oh no! My "fix" caused nested hash tables to not render properly :(. Back to the drawing board...

Collaborator

amolenaar commented Mar 10, 2016

Oh no! My "fix" caused nested hash tables to not render properly :(. Back to the drawing board...

@amolenaar

This comment has been minimized.

Show comment
Hide comment
@amolenaar

amolenaar Mar 19, 2016

Collaborator

#886 has been merged

Collaborator

amolenaar commented Mar 19, 2016

#886 has been merged

@amolenaar amolenaar closed this Mar 19, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment