Confluence
  1. Confluence
  2. CONF-23209

JIRA Issue Macro Will Not Render HTML When Displaying Custom Field In Column

    Details

    • Last commented by user?:
      true

      Description

      Description

      When retrieving information using JIRA Issue macro, with one of the column is from custom field, and if there are any HTML within the custom field the text returned will not be rendered as HTML, will be plain text instead, hence exposing all the HTML tags.

      Workaround

      Render the JIRA Issue macro as static instead, add the following line into the macro:

      |renderMode=static
      
      Screenshot

      1. Blad.jpg
        26 kB
      2. JIRA issue custom field HTML.png
        12 kB
      3. jira-issues-macro-html-tags.png
        126 kB
      4. screenshot-1.jpg
        68 kB

        Issue Links

          Activity

          HengHwa Loi [Atlassian] created issue -
          HengHwa Loi [Atlassian] made changes -
          Field Original Value New Value
          Description h5. Description

          When retrieving information using JIRA Issue macro, with one of the column is from custom field, and if there are any HTML within the custom field the text returned will not be rendered as HTML, will be plain text instead, hence exposing all the HTML tags.

          h5. Screenshot

          !JIRA issue custom field HTML.png|thumbnail!
          h5. Description

          When retrieving information using JIRA Issue macro, with one of the column is from custom field, and if there are any HTML within the custom field the text returned will not be rendered as HTML, will be plain text instead, hence exposing all the HTML tags.

          h5. Workaround

          Render the JIRA Issue macro as static instead, add the following line into the macro:

          {code}
          |renderMode=static
          {code}

          h5. Screenshot

          !JIRA issue custom field HTML.png|thumbnail!
          Vincent Choy [Atlassian] made changes -
          Status New [ 10034 ] Open [ 1 ]
          Hide
          Markus Borm added a comment -

          I'm dissatisfied with the workaround. I need the dynamic features! With renderMode static not only the sorting function is disabled, but also the width of the columns is fixed!!!

          For me this is not a workaround, it describes another configuration (not the default one), which has not the bug.

          Show
          Markus Borm added a comment - I'm dissatisfied with the workaround. I need the dynamic features! With renderMode static not only the sorting function is disabled, but also the width of the columns is fixed!!! For me this is not a workaround, it describes another configuration (not the default one), which has not the bug.
          Markus Borm made changes -
          Attachment screenshot-1.jpg [ 52632 ]
          Hide
          Markus Borm added a comment -

          Please consider my remark, in my opinion it's not a minor bug of this macro! Thank you.

          Show
          Markus Borm added a comment - Please consider my remark, in my opinion it's not a minor bug of this macro! Thank you.
          Hide
          Michal Szymanski added a comment -

          I have confluence 4.0 and even when you select renderType=static markup is displayed as normal text instead of HTML.

          Show
          Michal Szymanski added a comment - I have confluence 4.0 and even when you select renderType=static markup is displayed as normal text instead of HTML.
          Michal Szymanski made changes -
          Attachment Blad.jpg [ 54366 ]
          Michal Szymanski made changes -
          Comment [ Confluence 4.0 when renderType=static ]
          HengHwa Loi [Atlassian] made changes -
          Affects Version/s 4.0.3 [ 21191 ]
          Affects Version/s 4.0.2 [ 21190 ]
          Affects Version/s 4.0.1 [ 20990 ]
          Affects Version/s 4.0 [ 15862 ]
          Vincent Choy [Atlassian] made changes -
          Labels bugfix_dev_backlog bugfix_support_backlog dev_bugfix_backlog
          Hide
          Ronald Horner added a comment -

          We just upgraded to 4.0.3 and are seeing the same problem. Before everything used to render correctly with new lines and now we are seeing encoded special characters,

          &

          instead of just '&', and HTML tags like <br /> instead of a simple carriage return.

          Show
          Ronald Horner added a comment - We just upgraded to 4.0.3 and are seeing the same problem. Before everything used to render correctly with new lines and now we are seeing encoded special characters, &amp; instead of just '&', and HTML tags like <br /> instead of a simple carriage return.
          Ronald Horner made changes -
          Attachment jira-issues-macro-html-tags.png [ 55633 ]
          Ronald Horner made changes -
          Attachment jira-issues-macro-html-tags.png [ 55633 ]
          Ronald Horner made changes -
          Attachment jira-issues-macro-html-tags.png [ 55634 ]
          Hide
          Ronald Horner added a comment -

          Rendering as static does not fix the issue.

          Show
          Ronald Horner added a comment - Rendering as static does not fix the issue.
          Chris Kiehl [Atlassian] made changes -
          Labels bugfix_dev_backlog bugfix_support_backlog dev_bugfix_backlog bugfix_dev_backlog bugfix_support_backlog
          Chris Kiehl [Atlassian] made changes -
          Fix Version/s 4.0.x-Backlog [ 20597 ]
          Chris Kiehl [Atlassian] made changes -
          Fix Version/s 4.1.x-Backlog [ 22997 ]
          Fix Version/s 4.0.x-Backlog [ 20597 ]
          Chris Kiehl [Atlassian] made changes -
          Rank Ranked higher
          Chris Kiehl [Atlassian] made changes -
          Rank Ranked higher
          Paul Curren [Atlassian] made changes -
          Assignee Paul Curren [Atlassian] [ pcurren ]
          Paul Curren [Atlassian] made changes -
          Status Open [ 1 ] In Progress [ 3 ]
          Show
          Paul Curren [Atlassian] added a comment - This is https://studio.plugins.atlassian.com/browse/CONFJIRA-144
          Hide
          Paul Curren [Atlassian] added a comment -

          Forgive the question, but I am quite the noob when it comes to JIRA.

          How do I reproduce this problem? I cannot figure out how to create a custom field that uses HTML in JIRA. I tried using a select field with some HTML in the options but the JIRA issues macro code strips this to plain text anyway.

          Any pointers for configuring JIRA to reproduce this problem would be appreciated.

          Thanks.

          Show
          Paul Curren [Atlassian] added a comment - Forgive the question, but I am quite the noob when it comes to JIRA. How do I reproduce this problem? I cannot figure out how to create a custom field that uses HTML in JIRA. I tried using a select field with some HTML in the options but the JIRA issues macro code strips this to plain text anyway. Any pointers for configuring JIRA to reproduce this problem would be appreciated. Thanks.
          Hide
          Ronald Horner added a comment -

          If you look at the example screenshots you'll see in the Description field. All you need to do is put in a few carriage returns in your issue description on the JIRA side.

          If you look at the XML that is being parsed from the JIRA Filter Results you'll see the HTML or Wiki markup directly in the XML attributes itself. Here's an example of one of our JIRA issues that shows the issue.

          <item>
          	<title>
          		[TSE-559] Create a task for explaining the problem with the JIRA Confluence Issue macro
          	</title>
          	<link>http://localhost/jira/browse/TSE-559</link>
          	<project id="10030" key="TSE">Toolset Project</project>
          	<description>
          		<p>Investigate how to fix the HTML Rendering through configuration changes<br/> Investigate branching the official plugin<br/> Investigate writing a new plugin<br/> Implement the best methods</p>
          	</description>
          	<environment/>
          	<key id="36301">TSE-559</key>
          	<summary>
          		Create a task for explaining the problem with the JIRA Confluence Issue macro
          	</summary>
          	<type id="7" iconUrl="http://localhost/jira/images/icons/ico_story.png">Story</type>
          	<priority id="8" iconUrl="http://localhost/jira/images/icons/priority_major.gif">Three</priority>
          	<status id="1" iconUrl="http://localhost/jira/images/icons/status_open.gif">Open</status>
          	<resolution id="-1">Unresolved</resolution>
          	<assignee username="-1">Unassigned</assignee>
          	<reporter username="hornerr">Ronald Horner</reporter>
          	<labels></labels>
          	<created>Wed, 26 Oct 2011 22:30:41 +0000</created>
          	<updated>Fri, 28 Oct 2011 19:54:29 +0000</updated>
          	<component>JIRA</component>
          	<due/>
          	<votes>0</votes>
          	<watches>1</watches>
          	<comments>
          		<comment id="40243" author="hornerr" created="Fri, 28 Oct 2011 19:54:29 +0000">
          			The official plugin is being worked by Atlassian to fix this issue.<br/> <br/> <a href="https://jira.atlassian.com/browse/CONF-23209">https://jira.atlassian.com/browse/CONF-23209</a>
          		</comment>
          	</comments>
          	<attachments></attachments>
          	<subtasks></subtasks>
          	<customfields>
          		<customfield id="customfield_11440" key="com.pyxis.greenhopper.jira:gh-global-rank">
          			<customfieldname>Global Rank</customfieldname>
          			<customfieldvalues></customfieldvalues>
          		</customfield>
          		<customfield id="customfield_11540" key="com.pyxis.greenhopper.jira:gh-global-rank">
          			<customfieldname>Rank</customfieldname>
          			<customfieldvalues></customfieldvalues>
          		</customfield>
          		<customfield id="customfield_10012" key="com.atlassian.jira.plugin.system.customfieldtypes:float">
          			<customfieldname>Story Points</customfieldname>
          			<customfieldvalues>
          				<customfieldvalue>8.0</customfieldvalue>
          			</customfieldvalues>
          		</customfield>
          	</customfields>
          </item>
          
          Show
          Ronald Horner added a comment - If you look at the example screenshots you'll see in the Description field. All you need to do is put in a few carriage returns in your issue description on the JIRA side. If you look at the XML that is being parsed from the JIRA Filter Results you'll see the HTML or Wiki markup directly in the XML attributes itself. Here's an example of one of our JIRA issues that shows the issue. <item> <title> [TSE-559] Create a task for explaining the problem with the JIRA Confluence Issue macro </title> <link>http: //localhost/jira/browse/TSE-559</link> <project id= "10030" key= "TSE" >Toolset Project</project> <description> <p>Investigate how to fix the HTML Rendering through configuration changes<br/> Investigate branching the official plugin<br/> Investigate writing a new plugin<br/> Implement the best methods</p> </description> <environment/> <key id= "36301" >TSE-559</key> <summary> Create a task for explaining the problem with the JIRA Confluence Issue macro </summary> <type id= "7" iconUrl= "http: //localhost/jira/images/icons/ico_story.png" >Story</type> <priority id= "8" iconUrl= "http: //localhost/jira/images/icons/priority_major.gif" >Three</priority> <status id= "1" iconUrl= "http: //localhost/jira/images/icons/status_open.gif" >Open</status> <resolution id= "-1" >Unresolved</resolution> <assignee username= "-1" >Unassigned</assignee> <reporter username= "hornerr" >Ronald Horner</reporter> <labels></labels> <created>Wed, 26 Oct 2011 22:30:41 +0000</created> <updated>Fri, 28 Oct 2011 19:54:29 +0000</updated> <component>JIRA</component> <due/> <votes>0</votes> <watches>1</watches> <comments> <comment id= "40243" author= "hornerr" created= "Fri, 28 Oct 2011 19:54:29 +0000" > The official plugin is being worked by Atlassian to fix this issue.<br/> <br/> <a href= "https: //jira.atlassian.com/browse/CONF-23209" >https://jira.atlassian.com/browse/CONF-23209</a> </comment> </comments> <attachments></attachments> <subtasks></subtasks> <customfields> <customfield id= "customfield_11440" key= "com.pyxis.greenhopper.jira:gh-global-rank" > <customfieldname>Global Rank</customfieldname> <customfieldvalues></customfieldvalues> </customfield> <customfield id= "customfield_11540" key= "com.pyxis.greenhopper.jira:gh-global-rank" > <customfieldname>Rank</customfieldname> <customfieldvalues></customfieldvalues> </customfield> <customfield id= "customfield_10012" key= "com.atlassian.jira.plugin.system.customfieldtypes: float " > <customfieldname>Story Points</customfieldname> <customfieldvalues> <customfieldvalue>8.0</customfieldvalue> </customfieldvalues> </customfield> </customfields> </item>
          Hide
          Ronald Horner added a comment -

          Our field renderer for Comments is [Default Text Renderer] and Description is [Wiki Style Renderer] if that helps you at all. Those two fields show HTML markup in the results as displayed in Confluence.

          Show
          Ronald Horner added a comment - Our field renderer for Comments is [Default Text Renderer] and Description is [Wiki Style Renderer] if that helps you at all. Those two fields show HTML markup in the results as displayed in Confluence.
          Hide
          Paul Curren [Atlassian] added a comment -

          Thanks Ronald. I was actually aware of the description field exhibiting this behaviour. However the original issue appears to be related to custom fields and I cannot reproduce the problem at all with custom fields. Their content is treated slightly differently in the JIRA macro and they actually appear to be stripped of mark up.

          Any hints on reproducing with custom fields?

          Show
          Paul Curren [Atlassian] added a comment - Thanks Ronald. I was actually aware of the description field exhibiting this behaviour. However the original issue appears to be related to custom fields and I cannot reproduce the problem at all with custom fields. Their content is treated slightly differently in the JIRA macro and they actually appear to be stripped of mark up. Any hints on reproducing with custom fields?
          Hide
          Michelle Lorenz added a comment -

          Steps to reproduce

          In Jira

          1. Create a custom field, for example, a field called 'ReleaseNote'
            1. Specify the field as a 'Free Text Field'
            2. In the associated field configuration scheme, set the release note renderer to 'wiki style renderer'
          2. Create an issue in Jira, and populate the field with wiki markup, for example:
            Previously it was not possible to render custom fields from Jira as HTML in Confluence.  This has now been fixed.  The following markup is now supported
            # *bold*
            # _italics_
            # h3. headings
            # ^superscript
            # Code snippets, for example:
            {code:title=helloworld.java| borderStyle=dashed| borderColor=#ccc| titleBGColor=#F7D6C1| bgColor=#FFFFCE}
            /**
             * This program prints the string 'Hello World' to the screen.
             */
            class HelloWorld{
                public static void main(String[] args) {
                    System.out.println("Hello World!"); // Print the string.
                }
            }
            
            
          1. Generate and save a query showing the custom field. It renders the markup as expected.
          2. View as XML, copy URL

          In Confluence

          1. Insert a Jira macro
          2. Insert the copied URL
          3. Specify the custom field, ReleaseNote, to be displayed
          4. Save

          Expected: Content is rendered the same as in Jira, processing the wiki markup as HTML
          Actual: Content is converted to HTML but rendered as text, displaying as:

          <blockquote><p>Previously it was not possible to render custom fields from Jira as HTML in Confluence. This has now been fixed. The following markup is now supported</p> <ol> <li><b>bold</b></li> <li><em>italics</em></li> <li><h3><a name="headings"></a>headings</h3></li> <li>^superscript</li> <li>Code snippets, for example: <div class="code panel" style="background-color: #FFFFCE;border-color: #ccc;border-style: dashed;border-width: 1px;"><div class="codeHeader panelHeader" style="border-bottom-width: 1px;border-bottom-style: dashed;border-bottom-color: #ccc;background-color: #F7D6C1;"><b>helloworld.java</b></div><div class="codeContent panelContent" style="background-color: #FFFFCE;"> <pre class="code-java">/** * This program prints the string 'Hello World' to the screen. */ class HelloWorld{ <span class="code-keyword">public</span> <span class="code-keyword">static</span> void main(<span class="code-object">String</span>[] args) { <span class="code-object">System</span>.out.println(<span class="code-quote">"Hello World!"</span>); <span class="code-comment">// Print the string. </span> } }</pre> </div></div> </li> </ol> </blockquote> 
          
          Show
          Michelle Lorenz added a comment - Steps to reproduce In Jira Create a custom field, for example, a field called 'ReleaseNote' Specify the field as a 'Free Text Field' In the associated field configuration scheme, set the release note renderer to 'wiki style renderer' Create an issue in Jira, and populate the field with wiki markup, for example: Previously it was not possible to render custom fields from Jira as HTML in Confluence. This has now been fixed. The following markup is now supported # *bold* # _italics_ # h3. headings # ^superscript # Code snippets, for example: {code:title=helloworld.java| borderStyle=dashed| borderColor=#ccc| titleBGColor=#F7D6C1| bgColor=#FFFFCE} /** * This program prints the string 'Hello World' to the screen. */ class HelloWorld{ public static void main( String [] args) { System .out.println( "Hello World!" ); // Print the string. } } Generate and save a query showing the custom field. It renders the markup as expected. View as XML, copy URL In Confluence Insert a Jira macro Insert the copied URL Specify the custom field, ReleaseNote, to be displayed Save Expected: Content is rendered the same as in Jira, processing the wiki markup as HTML Actual: Content is converted to HTML but rendered as text, displaying as: <blockquote><p>Previously it was not possible to render custom fields from Jira as HTML in Confluence. This has now been fixed. The following markup is now supported</p> <ol> <li><b>bold</b></li> <li><em>italics</em></li> <li><h3><a name= "headings" ></a>headings</h3></li> <li>^superscript</li> <li>Code snippets, for example: <div class= "code panel" style= "background-color: #FFFFCE;border-color: #ccc;border-style: dashed;border-width: 1px;" ><div class= "codeHeader panelHeader" style= "border-bottom-width: 1px;border-bottom-style: dashed;border-bottom-color: #ccc;background-color: #F7D6C1;" ><b>helloworld.java</b></div><div class= "codeContent panelContent" style= "background-color: #FFFFCE;" > <pre class= "code-java" >/** * This program prints the string 'Hello World' to the screen. */ class HelloWorld{ <span class= "code-keyword" > public </span> <span class= "code-keyword" > static </span> void main(<span class= "code-object" > String </span>[] args) { <span class= "code-object" > System </span>.out.println(<span class= "code-quote" > "Hello World!" </span>); <span class= "code-comment" > // Print the string. </span> } }</pre> </div></div> </li> </ol> </blockquote>
          Hide
          Paul Curren [Atlassian] added a comment - - edited

          Thanks Michelle. That helped a lot. And to give Ronald his due, I can now see the similarity to the description field handling he was describing.

          So to summarise the problem -

          Render Mode/Field Type "Custom" "Built-in"
          static Escapes HTML values Escapes HTML values
          dynamic Escapes HTML values Displays correctly
          Show
          Paul Curren [Atlassian] added a comment - - edited Thanks Michelle. That helped a lot. And to give Ronald his due, I can now see the similarity to the description field handling he was describing. So to summarise the problem - Render Mode/Field Type "Custom" "Built-in" static Escapes HTML values Escapes HTML values dynamic Escapes HTML values Displays correctly
          Hide
          Paul Curren [Atlassian] added a comment - - edited

          The problem with displaying fields (custom or otherwise) from JIRA is that the report received from JIRA provides no information about how the field data has been rendered. In addition, field renderers are a plugin point in JIRA so even if you did get such information it could be potentially any value and so not necessarily meaningful.

          These problems apply to standard fields such as description as well although it seems that the jiraissues macro in dynamic mode makes an assumption about the description value. I will make the static render mode behave consistently with this even though in some unusual field configuration cases this assumption could be wrong. At least both static and dynamic modes would break in the same way in these cases.

          So the only remaining option I see for custom fields is to allow the user of the jiraissues macro to state whether a field is safe for unencoded display or not. So would it be useful to the people encountering this problem if I provided an additional parameter where you can name the fields that are safe for unencoded display?

          e.g.

          {jiraissues:url=<url>|columns=type,key,description,customField1,customField2|htmlColumns=customField2}
          

          This isn't elegant but there's no dynamic way of safely discovering the safe columns. What do you think?

          Show
          Paul Curren [Atlassian] added a comment - - edited The problem with displaying fields (custom or otherwise) from JIRA is that the report received from JIRA provides no information about how the field data has been rendered. In addition, field renderers are a plugin point in JIRA so even if you did get such information it could be potentially any value and so not necessarily meaningful. These problems apply to standard fields such as description as well although it seems that the jiraissues macro in dynamic mode makes an assumption about the description value. I will make the static render mode behave consistently with this even though in some unusual field configuration cases this assumption could be wrong. At least both static and dynamic modes would break in the same way in these cases. So the only remaining option I see for custom fields is to allow the user of the jiraissues macro to state whether a field is safe for unencoded display or not. So would it be useful to the people encountering this problem if I provided an additional parameter where you can name the fields that are safe for unencoded display? e.g. {jiraissues:url=<url>|columns=type,key,description,customField1,customField2|htmlColumns=customField2} This isn't elegant but there's no dynamic way of safely discovering the safe columns. What do you think?
          Hide
          Ronald Horner added a comment -

          Is there any reason why we are escaping the XML values? Does it open an XSS vulnerability? It looks like JIRA isn't returning any unconverted wiki markup anymore so everything is HTML (which may need to be decoded).

          Show
          Ronald Horner added a comment - Is there any reason why we are escaping the XML values? Does it open an XSS vulnerability? It looks like JIRA isn't returning any unconverted wiki markup anymore so everything is HTML (which may need to be decoded).
          Hide
          Paul Curren [Atlassian] added a comment - - edited

          Yes, the XSS issue is what is bothering me. Well that and the potential to generate broken HTML and break the display of the whole page.

          A custom field implementation can specify a different XML template from that which it uses to render in JIRA. So just because a field safely displays in JIRA doesn't tell you anything about what you are going to receive over the XML API.

          If a custom field happens to output for instance a nasty collection of '<' or '>' if we don't escape it on display in Confluence then we potentially break display of the whole page.

          Show
          Paul Curren [Atlassian] added a comment - - edited Yes, the XSS issue is what is bothering me. Well that and the potential to generate broken HTML and break the display of the whole page. A custom field implementation can specify a different XML template from that which it uses to render in JIRA. So just because a field safely displays in JIRA doesn't tell you anything about what you are going to receive over the XML API. If a custom field happens to output for instance a nasty collection of '<' or '>' if we don't escape it on display in Confluence then we potentially break display of the whole page.
          Hide
          Mike Curwen added a comment -

          one problem I have with the new parameter is that you now can't order your columns.

          Show
          Mike Curwen added a comment - one problem I have with the new parameter is that you now can't order your columns.
          Hide
          Paul Curren [Atlassian] added a comment -

          Mike, the existing columns parameter would be used to list all columns as before.
          The columns within that parameter that should be HTML will be listed in the htmlColumns parameter.

          Perhaps it needs a better name: 'htmlsafe'?

          Show
          Paul Curren [Atlassian] added a comment - Mike, the existing columns parameter would be used to list all columns as before. The columns within that parameter that should be HTML will be listed in the htmlColumns parameter. Perhaps it needs a better name: 'htmlsafe'?
          Hide
          Mike Curwen added a comment -

          for some reason I didn't see in your example that customField2 was in there twice. Glad this will also fix my reported issue (CONF-24227)

          I do like "htmlsafe" better, for what it's worth. I wonder if it's better to be even more explicit about what we're doing? something like "disableAntiXSS" ?

          Show
          Mike Curwen added a comment - for some reason I didn't see in your example that customField2 was in there twice. Glad this will also fix my reported issue ( CONF-24227 ) I do like "htmlsafe" better, for what it's worth. I wonder if it's better to be even more explicit about what we're doing? something like "disableAntiXSS" ?
          Hide
          Paul Curren [Atlassian] added a comment -

          Thanks Mike.

          I not a big fan of 'disableAntiXSS' because it's not really the whole story. The truest thing you can say with this parameter is that the content is suitable for pushing straight into the HTML render.

          I've gone with 'htmlSafeCustomFields'. The ...CustomFields part because the parameter will only be respected for custom fields. Fixed fields such as description are handled the way they are handled irrespective of this new parameter (noting that I have also fixed description handling in static mode to match dynamic mode).

          This work is going through internal review at the moment. It should be available via the Plugin Manager in a couple of days and will also be bundled with version 4.1.3 of Confluence. (It was too late for 4.1.2 which is due out any minute now.)

          Show
          Paul Curren [Atlassian] added a comment - Thanks Mike. I not a big fan of 'disableAntiXSS' because it's not really the whole story. The truest thing you can say with this parameter is that the content is suitable for pushing straight into the HTML render. I've gone with 'htmlSafeCustomFields'. The ...CustomFields part because the parameter will only be respected for custom fields. Fixed fields such as description are handled the way they are handled irrespective of this new parameter (noting that I have also fixed description handling in static mode to match dynamic mode). This work is going through internal review at the moment. It should be available via the Plugin Manager in a couple of days and will also be bundled with version 4.1.3 of Confluence. (It was too late for 4.1.2 which is due out any minute now.)
          Paul Curren [Atlassian] made changes -
          Status In Progress [ 3 ] Technical Review [ 10028 ]
          Hide
          Paul Curren [Atlassian] added a comment -

          Hello again interested people

          Some concern has been raised over this solution. It asks users of the jiraissues macro to make the decision on whether certain fields are safe to be used on a page. We are worried that the users of the macro might not be in the best position to properly make this decision.

          Instead a site administrator could maintain a list of fields per remote JIRA server that are safe for rendering in HTML. This would dp away with the need for a user to specify safe fields but could well mean more frequent requests to an administrator to configure additional fields a user requires.

          Any thoughts on this point?

          Show
          Paul Curren [Atlassian] added a comment - Hello again interested people Some concern has been raised over this solution. It asks users of the jiraissues macro to make the decision on whether certain fields are safe to be used on a page. We are worried that the users of the macro might not be in the best position to properly make this decision. Instead a site administrator could maintain a list of fields per remote JIRA server that are safe for rendering in HTML. This would dp away with the need for a user to specify safe fields but could well mean more frequent requests to an administrator to configure additional fields a user requires. Any thoughts on this point?
          Paul Curren [Atlassian] made changes -
          Status Technical Review [ 10028 ] Open [ 1 ]
          Dave Loeng [Atlassian] made changes -
          Status Open [ 1 ] In Progress [ 3 ]
          Paul Curren [Atlassian] made changes -
          Status In Progress [ 3 ] Open [ 1 ]
          Hide
          Markus Borm added a comment -

          From my point as user and administrator I would prefer the solution "a site administrator could maintain a list of fields per remote JIRA server that are safe for rendering in HTML"

          Show
          Markus Borm added a comment - From my point as user and administrator I would prefer the solution "a site administrator could maintain a list of fields per remote JIRA server that are safe for rendering in HTML"
          Paul Curren [Atlassian] made changes -
          Status Open [ 1 ] In Progress [ 3 ]
          Hide
          Paul Curren [Atlassian] added a comment - - edited

          Version 4.0.8 has been released which fixes the problem rendering the description field in static mode.

          Show
          Paul Curren [Atlassian] added a comment - - edited Version 4.0.8 has been released which fixes the problem rendering the description field in static mode.
          Hide
          Paul Curren [Atlassian] added a comment -

          I'm afraid this issue will not be fixed.

          We originally intended to implement an 'htmlSafe' parameter for use by authors. However this is too large a security hole. Anyone could set up a JIRA instance and then feed any data they like via the jiraissues macro into the page of an unsuspecting viewer.

          An alternative approach would be to allow only administrators to configure the safe fields, per server. However this introduces quite a load on an administrator. Not only do they need to be on top of the safety of all fields across all instances of JIRA their users want to access they also need to constantly review this information as the various JIRA instances have further plugins installed.

          In practise an administrator is very likely to enable most fields requested by their users making this approach as dangerous as the user driven approach.

          Finally, we investigated an elegant approach of running all the data received from JIRA through our security/cleaning process. Unfortunately though this has a fairly massive impact on both peak CPU and peak memory usage. Enabling this approach would cause our own internal servers to run out of memory frequently and would have a similar negative impact on most Confluence installations.

          So in summary, I'm afraid at this point in time we won't be fixing this issue and so the clearest approach to take is to close this issue with the status "Won't Fix".

          If you need to take this requirement further I'd recommend finding an Atlassian Partner who may be able to come up with a solution specific to your particular needs.

          Show
          Paul Curren [Atlassian] added a comment - I'm afraid this issue will not be fixed. We originally intended to implement an 'htmlSafe' parameter for use by authors. However this is too large a security hole. Anyone could set up a JIRA instance and then feed any data they like via the jiraissues macro into the page of an unsuspecting viewer. An alternative approach would be to allow only administrators to configure the safe fields, per server. However this introduces quite a load on an administrator. Not only do they need to be on top of the safety of all fields across all instances of JIRA their users want to access they also need to constantly review this information as the various JIRA instances have further plugins installed. In practise an administrator is very likely to enable most fields requested by their users making this approach as dangerous as the user driven approach. Finally, we investigated an elegant approach of running all the data received from JIRA through our security/cleaning process. Unfortunately though this has a fairly massive impact on both peak CPU and peak memory usage. Enabling this approach would cause our own internal servers to run out of memory frequently and would have a similar negative impact on most Confluence installations. So in summary, I'm afraid at this point in time we won't be fixing this issue and so the clearest approach to take is to close this issue with the status "Won't Fix". If you need to take this requirement further I'd recommend finding an Atlassian Partner who may be able to come up with a solution specific to your particular needs.
          Paul Curren [Atlassian] made changes -
          Status In Progress [ 3 ] Resolved [ 5 ]
          Resolution Won't Fix [ 2 ]
          Dave Loeng [Atlassian] made changes -
          Fix Version/s 4.1.3 [ 23490 ]
          Dave Loeng [Atlassian] made changes -
          Fix Version/s 4.1.x-Backlog [ 22997 ]
          Hide
          Steve Syrett added a comment -

          Hello Paul,

          I am also disappointed that some option could not be implemented to address this. I do understand the security concerns – we run into them constantly with our own products. However, it seems that using the Jira issue macro to display content in the same way that it displays in Jira is important enough warrant some solution, even if it has to be enabled specifically by the system administrator.

          We are trying to implement a Confluence/Jira integration in our organization because there are features that each solution provides that are desirable to us, but I am running into lots of push-back on its use when things don't work the same way in both systems (with the editor being then main gripe at the moment ). The integration lets me build solutions which hide much of the complexity from my end users, but we keep running into small issues like this that make things a bit less usable.

          I do like the products, however, and look forward to improvements in future releases!

          Show
          Steve Syrett added a comment - Hello Paul, I am also disappointed that some option could not be implemented to address this. I do understand the security concerns – we run into them constantly with our own products. However, it seems that using the Jira issue macro to display content in the same way that it displays in Jira is important enough warrant some solution, even if it has to be enabled specifically by the system administrator. We are trying to implement a Confluence/Jira integration in our organization because there are features that each solution provides that are desirable to us, but I am running into lots of push-back on its use when things don't work the same way in both systems (with the editor being then main gripe at the moment ). The integration lets me build solutions which hide much of the complexity from my end users, but we keep running into small issues like this that make things a bit less usable. I do like the products, however, and look forward to improvements in future releases!
          Hide
          Ronald Horner added a comment -

          Paul,

          This is too bad. I've forked the plugin and added in the changes to get the description field to render HTML in static mode. This is at least a start. The concerns for not implementing this are not stronger than the user base's desire to have them. It is very confusing to have something display correctly in JIRA and not in Confluence. I may just add a checkbox feature to this plugin to allow rendering of HTML custom fields. No lists, just simply check for HTML in the value and if it exists render it as HTML and not escape all of the characters.

          The security concerns are legitimate but at any time you allow the user to use HTML it is possible to introduce security holes. We can say with a particular certainty that if our JIRA instance was compromised and used to insert XSS attacks against our Confluence instance, then we have much bigger fish to fry.

          Show
          Ronald Horner added a comment - Paul, This is too bad. I've forked the plugin and added in the changes to get the description field to render HTML in static mode. This is at least a start. The concerns for not implementing this are not stronger than the user base's desire to have them. It is very confusing to have something display correctly in JIRA and not in Confluence. I may just add a checkbox feature to this plugin to allow rendering of HTML custom fields. No lists, just simply check for HTML in the value and if it exists render it as HTML and not escape all of the characters. The security concerns are legitimate but at any time you allow the user to use HTML it is possible to introduce security holes. We can say with a particular certainty that if our JIRA instance was compromised and used to insert XSS attacks against our Confluence instance, then we have much bigger fish to fry.
          Hide
          Paul Curren [Atlassian] added a comment - - edited

          The point you are missing Ronald is that it is not your JIRA instance that needs to be compromised.

          The jira issues macro can be used to access any JIRA instance in the world. As an attacker I simply need to set up my own JIRA instance configured in any malicious way I want. In fact, I don't even need a JIRA instance, I just need a simple server that will send my attack payload in an XML format the jiraissues macro understands.

          Then if I can get a jiraissues macro on a page in your Confluence install (via whatever means) I have the potential to attack everybody in your organisation who views that particular page.

          The security hole is pretty massive!

          Show
          Paul Curren [Atlassian] added a comment - - edited The point you are missing Ronald is that it is not your JIRA instance that needs to be compromised. The jira issues macro can be used to access any JIRA instance in the world. As an attacker I simply need to set up my own JIRA instance configured in any malicious way I want. In fact, I don't even need a JIRA instance, I just need a simple server that will send my attack payload in an XML format the jiraissues macro understands. Then if I can get a jiraissues macro on a page in your Confluence install (via whatever means) I have the potential to attack everybody in your organisation who views that particular page. The security hole is pretty massive!
          Hide
          Ronald Horner added a comment -

          Ah I see. So why not use a white list for trusted JIRA installations?

          Show
          Ronald Horner added a comment - Ah I see. So why not use a white list for trusted JIRA installations?
          Hide
          Paul Curren [Atlassian] added a comment -

          Ronald, a whitelist or the inbuilt 'Trusted Applications' mechanisms are possibilities and once something like that was implemented and mandatory then we could reconsider this feature.

          But any such mandatory mechanism will have a major impact on existing users of jira issue macros. Suddenly all of your usages will break so we will need to be careful about the introduction of such a feature. We'll need to ensure admin's are aware of the transition, or provide some kind of automation around initial population of the whitelist.

          I think you are right though that ultimately that is the direction the jiraissues macro will need to take to provide reasonable security.

          Show
          Paul Curren [Atlassian] added a comment - Ronald, a whitelist or the inbuilt 'Trusted Applications' mechanisms are possibilities and once something like that was implemented and mandatory then we could reconsider this feature. But any such mandatory mechanism will have a major impact on existing users of jira issue macros. Suddenly all of your usages will break so we will need to be careful about the introduction of such a feature. We'll need to ensure admin's are aware of the transition, or provide some kind of automation around initial population of the whitelist. I think you are right though that ultimately that is the direction the jiraissues macro will need to take to provide reasonable security.
          Hide
          Ronald Horner added a comment -

          So is this issue truly a Won't Fix? It seems like you still have feelers out to your team and active involvement from the community.

          Show
          Ronald Horner added a comment - So is this issue truly a Won't Fix? It seems like you still have feelers out to your team and active involvement from the community.
          Hide
          Vitaly Osipov [Atlassian] added a comment -

          Everyone,

          There was indeed a discussion about (eventually) only allowing extracting content from JIRA instances that Applinks knows about. This is good for miultiple reasons. At the same time this is a big task, especially the migration part of it, since the macro's behaviour will change significantly. We hope to do this at some point in the future, with no specific plans at the moment.

          How bad it is to allow rendering HTML in custom fields: not only a random JIRA instance can be used to embed arbitrary content into your Confluence - any web server that produces XML parseable by the JIRA issues macro will do. Basically this turns your Confluence into a proxy for arbitrary external content, which in turn can be used e.g for downloading malware or stealing your data.

          We are in the process of improving security of the default setup of our products, since they are more and more often used on the Internet, as opposed to strictly on-premises behind a firewall. OnDemand is also a huge driver here. This process can, in a few cases like this, lead to inconvenience where the initial setup of a component (a macro) was less secure to start with.

          One of the ways out of the conundrum will be for us to introduce a magic configuration setting in the product - "am I on the internet?". It would permit a number of options that are unacceptable in the Internet scenario. This will not be happening soon, but check back in 6 months or so.

          By the way, if you find a security vulnerability that has not been fixed, please do not discuss it here and follow How to report a security issue instead.

          Show
          Vitaly Osipov [Atlassian] added a comment - Everyone, There was indeed a discussion about (eventually) only allowing extracting content from JIRA instances that Applinks knows about. This is good for miultiple reasons. At the same time this is a big task, especially the migration part of it, since the macro's behaviour will change significantly. We hope to do this at some point in the future, with no specific plans at the moment. How bad it is to allow rendering HTML in custom fields: not only a random JIRA instance can be used to embed arbitrary content into your Confluence - any web server that produces XML parseable by the JIRA issues macro will do. Basically this turns your Confluence into a proxy for arbitrary external content, which in turn can be used e.g for downloading malware or stealing your data. We are in the process of improving security of the default setup of our products, since they are more and more often used on the Internet, as opposed to strictly on-premises behind a firewall. OnDemand is also a huge driver here. This process can, in a few cases like this, lead to inconvenience where the initial setup of a component (a macro) was less secure to start with. One of the ways out of the conundrum will be for us to introduce a magic configuration setting in the product - "am I on the internet?". It would permit a number of options that are unacceptable in the Internet scenario. This will not be happening soon, but check back in 6 months or so. By the way, if you find a security vulnerability that has not been fixed, please do not discuss it here and follow How to report a security issue instead.
          Hide
          Markus Borm added a comment -

          Hi,
          when reading this, I had the following idea. Would it not be useful to provide a second "Jira Issue Macro", like "Jira Issue Macro trusted". This "trusted" macro allows only connections to Jira instances that Applinks knows about. This way the migration process would be not so big or? (at least for atlassian I guess and for me as user/administrator it would be a great way)
          I would be glad if you could consider this way. Thank you!

          Show
          Markus Borm added a comment - Hi, when reading this, I had the following idea. Would it not be useful to provide a second "Jira Issue Macro", like "Jira Issue Macro trusted". This "trusted" macro allows only connections to Jira instances that Applinks knows about. This way the migration process would be not so big or? (at least for atlassian I guess and for me as user/administrator it would be a great way) I would be glad if you could consider this way. Thank you!
          Paul Curren [Atlassian] made changes -
          Link This issue is related to CONF-24422 [ CONF-24422 ]
          Hide
          Ronald Horner added a comment -

          Will you be updating the documentation? I can't seem to get the htmlSafeCustomFields field to work with custom field names that have a space in them.

          http://confluence.atlassian.com/display/DOC/JIRA+Issues+Macro

          Show
          Ronald Horner added a comment - Will you be updating the documentation? I can't seem to get the htmlSafeCustomFields field to work with custom field names that have a space in them. http://confluence.atlassian.com/display/DOC/JIRA+Issues+Macro
          Hide
          Paul Curren [Atlassian] added a comment - - edited

          Hi Ronald.

          At the end of the day it was decided that 'htmlSafeCustomFields' parameter was not a secure approach and it was dropped. This isn't 100% clear from the discussion on the issue because the final related comment was 'restricted' due to it discussing security concerns.

          Hopefully I can clear up any confusion here: the 'htmlSafeCustomFields' parameter was not implemented.

          A more secure fix was implemented and is described in the documentation for the JIRA Issues Macro.

          Show
          Paul Curren [Atlassian] added a comment - - edited Hi Ronald. At the end of the day it was decided that 'htmlSafeCustomFields' parameter was not a secure approach and it was dropped. This isn't 100% clear from the discussion on the issue because the final related comment was 'restricted' due to it discussing security concerns. Hopefully I can clear up any confusion here: the 'htmlSafeCustomFields' parameter was not implemented. A more secure fix was implemented and is described in the documentation for the JIRA Issues Macro .
          Hide
          Paul Curren [Atlassian] added a comment -

          Hi Markus. I apologise for directing you to a restricted issue, and I'll edit my original comment to no longer refer to it. Likewise I'll remove your comment to avoid confusion for viewers of this issue.

          The pertinent information about how this issue was fixed has been added to the JIRA Issues Macro documentation on CAC.

          Hopefully this covers what you need to know but if you have further questions just let me know.

          Show
          Paul Curren [Atlassian] added a comment - Hi Markus. I apologise for directing you to a restricted issue, and I'll edit my original comment to no longer refer to it. Likewise I'll remove your comment to avoid confusion for viewers of this issue. The pertinent information about how this issue was fixed has been added to the JIRA Issues Macro documentation on CAC. Hopefully this covers what you need to know but if you have further questions just let me know.
          Paul Curren [Atlassian] made changes -
          Comment [ Hi Paul,

          I'm not able to read/see CONF-24422
          When I call "https://jira.atlassian.com/browse/CONF-24422" I get "Permission Violation".
          Is there not restricted information?

          Thank you
          Markus ]
          William Zanchet [Atlassian] made changes -
          Link This issue is duplicated by CONF-25335 [ CONF-25335 ]
          William Zanchet [Atlassian] made changes -
          Link This issue relates to CONF-26521 [ CONF-26521 ]
          Hide
          Alla Sapozhnikova added a comment -

          Hi Paul,
          Actually, the fix that is documented in JIRA Issues Macro documentation does not work. See https://support.atlassian.com/browse/CSP-87350 and https://jira.atlassian.com/browse/CONF-26521.

          Show
          Alla Sapozhnikova added a comment - Hi Paul, Actually, the fix that is documented in JIRA Issues Macro documentation does not work. See https://support.atlassian.com/browse/CSP-87350 and https://jira.atlassian.com/browse/CONF-26521 .
          Hide
          Paul Curren [Atlassian] added a comment -

          Hi there.

          This issue is actually resolved as 'Wont Fix'. The fix you are interested in is CONF-24422 which is fixed in 4.1.6.

          I hope that helps.

          Show
          Paul Curren [Atlassian] added a comment - Hi there. This issue is actually resolved as 'Wont Fix'. The fix you are interested in is CONF-24422 which is fixed in 4.1.6. I hope that helps.
          Paul Curren [Atlassian] made changes -
          Fix Version/s 4.1.3 [ 23490 ]
          Hide
          Alla Sapozhnikova added a comment -

          Hi Paul,

          Then why are the issues not linked? And I cannot see it when I try searching for it.

          Thank you.
          Alla

          Show
          Alla Sapozhnikova added a comment - Hi Paul, Then why are the issues not linked? And I cannot see it when I try searching for it. Thank you. Alla
          Anatoli Kazatchkov [Administrative Account] made changes -
          Workflow Confluence Bug Workflow [ 344515 ] New Confluence Default Workflow [ 477259 ]
          Hide
          Karie Kelly added a comment -

          I'm confused regarding this. One of the fields that will not render is the Summary field which is a standard JIRA issue, required field - it is not a custom field. Are you saying Atlassian doesn't support their own required fields or that they have created fields that, if exposed as indicated, is a security risk? Please advise.

          Show
          Karie Kelly added a comment - I'm confused regarding this. One of the fields that will not render is the Summary field which is a standard JIRA issue, required field - it is not a custom field. Are you saying Atlassian doesn't support their own required fields or that they have created fields that, if exposed as indicated, is a security risk? Please advise.
          Hide
          Markus Borm added a comment -

          Hi Karie,

          which versions do you use? This issue was fixed a long time ago from atlassian...

          Regards
          Markus

          Show
          Markus Borm added a comment - Hi Karie, which versions do you use? This issue was fixed a long time ago from atlassian... Regards Markus
          Hide
          Karie Kelly added a comment -

          The most recent: Confluence 5.1.3 and JIRA 6.0.2. As stated, we have no issues with any field content being included in an export except for the issue Summary field. We were referred to this issue as the reason and that it wouldn't be fixed.

          Show
          Karie Kelly added a comment - The most recent: Confluence 5.1.3 and JIRA 6.0.2. As stated, we have no issues with any field content being included in an export except for the issue Summary field. We were referred to this issue as the reason and that it wouldn't be fixed.
          Hide
          Paul Curren [Atlassian] added a comment -

          Hi Karie.

          This should work, as documented here. That is to say, you need to have a trust relationship configured between Confluence and JIRA.

          Does that help any?

          Show
          Paul Curren [Atlassian] added a comment - Hi Karie. This should work, as documented here . That is to say, you need to have a trust relationship configured between Confluence and JIRA. Does that help any?
          Hide
          Karie Kelly added a comment -

          We have a trusted connection. In this case, if you use the JIRA issues macro in dynamic mode, the JIRA issue Summary field displays on screen, but the content of just that one field (e.g. Other field content is fine, both base and custom fields), except for the Summary field. The Summary field is blank. If the JIRA issues macro is setup in static mode, one fields display on screen except for the Summary field – the content is empty and the exports are empty.

          From: "Paul Curren [Atlassian] (JIRA)" <jira@atlassian.com<jira@atlassian.com>>
          Date: Sunday, June 23, 2013 9:15 PM
          To: Karie Kelly <karie.kelly@phytel.com<karie.kelly@phytel.com>>
          Subject: [JIRA] (CONF-23209) JIRA Issue Macro Will Not Render HTML When Displaying Custom Field In Column

          https://jira.atlassian.com/s/en_UKkdyw0-1988229788/6097/9/_/images/icon-jira-logo.png
          https://jira.atlassian.com/secure/useravatar?ownerId=pcurren&avatarId=30380
          Paul Curren [Atlassian]<https://jira.atlassian.com/secure/ViewProfile.jspa?name=pcurren> commented on https://jira.atlassian.com/images/icons/issuetypes/bug.png CONF-23209<https://jira.atlassian.com/browse/CONF-23209>
          JIRA Issue Macro Will Not Render HTML When Displaying Custom Field In Column<https://jira.atlassian.com/browse/CONF-23209>

          Hi Karie.

          This should work, as documented here<https://confluence.atlassian.com/display/DOC/JIRA+Issues+Macro#JIRAIssuesMacro-renderinghtmlfromjira>. That is to say, you need to have a trust relationship configured between Confluence and JIRA.

          Does that help any?

          This message is automatically generated by JIRA.
          If you think it was sent incorrectly, please contact your JIRA administrators
          For more information on JIRA, see: http://www.atlassian.com/software/jira

          Show
          Karie Kelly added a comment - We have a trusted connection. In this case, if you use the JIRA issues macro in dynamic mode, the JIRA issue Summary field displays on screen, but the content of just that one field (e.g. Other field content is fine, both base and custom fields), except for the Summary field. The Summary field is blank. If the JIRA issues macro is setup in static mode, one fields display on screen except for the Summary field – the content is empty and the exports are empty. From: "Paul Curren [Atlassian] (JIRA)" <jira@atlassian.com< jira@atlassian.com >> Date: Sunday, June 23, 2013 9:15 PM To: Karie Kelly <karie.kelly@phytel.com< karie.kelly@phytel.com >> Subject: [JIRA] ( CONF-23209 ) JIRA Issue Macro Will Not Render HTML When Displaying Custom Field In Column https://jira.atlassian.com/s/en_UKkdyw0-1988229788/6097/9/_/images/icon-jira-logo.png https://jira.atlassian.com/secure/useravatar?ownerId=pcurren&avatarId=30380 Paul Curren [Atlassian] < https://jira.atlassian.com/secure/ViewProfile.jspa?name=pcurren > commented on https://jira.atlassian.com/images/icons/issuetypes/bug.png CONF-23209 < https://jira.atlassian.com/browse/CONF-23209 > JIRA Issue Macro Will Not Render HTML When Displaying Custom Field In Column< https://jira.atlassian.com/browse/CONF-23209 > Hi Karie. This should work, as documented here< https://confluence.atlassian.com/display/DOC/JIRA+Issues+Macro#JIRAIssuesMacro-renderinghtmlfromjira >. That is to say, you need to have a trust relationship configured between Confluence and JIRA. Does that help any? This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
          Steve Haffenden [Atlassian Bugmaster] made changes -
          Fix Version/s N/A [ 37219 ]
          Steve Haffenden [Atlassian Bugmaster] made changes -
          Fix Version/s N/A [ 37219 ]

            People

            • Votes:
              9 Vote for this issue
              Watchers:
              17 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:
                Last commented:
                43 weeks, 2 days ago