Currently we have several dynamic macros that allow the “rich-text” body type but we’re having difficulty getting Confluence macros placed within ours to work correctly. I’m keen to know if anyone else has had any related issues and if you’ve found any solutions to the problem.
When a Confluence page is loaded, on the server side we:
- Request the macro’s body
- Use “/rest/api/contentbody/convert/view” with the required expand parameters set to produce the HTML for the content of the macro and the needed JS/CSS resources (webresource.superbatch.metatags, webresource.superbatch.tags.all, webresource.tags.all).
- Insert this in the correct order into the HTML response from the server and thus is then loaded into our macro’s iframe within the Confluence page.
Some macros work, some don’t. In particular the “JIRA Issue/Filter” macro is throwing errors when it attempts to load.
Based on the error below is appears to be related to the REST interface to WRM (web resource manager?) and is clearly caused by CORS attempting to lazy load web resources required by the JIRA Issue/Filter (this JS code will obviously be running in the context of our domain within the iframe).
OPTIONS https://xyz.atlassian.net/wiki/rest/webResources/1.0/resources 415 send @ jquery-1.7.2-confluence-v5.js:20 ajax @ jquery-1.7.2-confluence-v5.js:20 _getScriptsForResources @ batch.js?locale=en-GB:124 _resolveAsync @ batch.js?locale=en-GB:124 l @ batch.js?locale=en-GB:124 require @ batch.js?locale=en-GB:124 WRM.require @ batch.js?locale=en-GB:129 (anonymous) @ confluence.extra.jira:jira-issues-view-mode-resources.js?locale=en-GB:5 k @ batch.js?locale=en-GB:1076 XMLHttpRequest cannot load https://xyz.atlassian.net/wiki/rest/webResources/1.0/resources. Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'https://abcdefg.au.ngrok.io' is therefore not allowed access. The response had HTTP status code 415.