Confluence REST API 404 from atlassian-connect-express macro

[Scott]

A user of one of my Confluence Cloud marketplace add-ons has reported an error, where my macro is not responding.

From my server logs I can see that my add-on is getting a 404 Not Found error when calling the Confluence REST API to fetch the macro body.

As per the documentation for a Dynamic Content Macro, when the macroTruncated parameter is true and the outputType is not "preview", my add-on uses the REST API to fetch the full macro content.

Here is the relevant piece of node.js code:

// If we have the full macro body already, or we're in preview mode, use what was passed in
if (!macroTruncated || isPreview) {
	renderMacro(res, url, macroBody, macroTruncated);
} else {
	// ...otherwise get the full macro body using the Confluence REST API
	addon.httpClient(req).get({
		uri: "/rest/api/content/" + pageId + "/history/" + pageVersion + "/macro/id/" + macroId,
	}, function(error, response, macroBody) {
		if (!error && response.statusCode == 200) {
			try {
				var macro = JSON.parse(macroBody);
			} catch (e) {
				res.status(500).send("Unable to process macro body");
				return;
			}

			renderMacro(res, url, macro.body);
		} else {
			res.status(response.statusCode).send("Unable to retrieve macro body from Confluence");
		}
	});
}

For this particular user (other users of my add-on are not reporting any issues), the call to /rest/api/content/{pageId}/history/{pageVersion}/macro/id/{macroId} is returning a 404.

Looking at the REST API documentation for this resource, a 404 is "Returned if there is no content with the given id, or if the calling user does not have permission to view the content, or there is no macro matching the given id or hash."

Confluence is passing the macroId to my add-on server, and I can see the first 128 bytes of the macro body in the request; so the only other reason that a 404 might occur is "if the calling user does not have permission to view the content".

Under what circumstances might a Confluence Cloud user editing a page and adding a macro to the page NOT have permission to view the content?  Would a page restriction cause this?

I'm at a loss as to what response I can provide to my customer on why a REST API call from my Connect add-on to their Cloud instance is getting a 404 error.

[Scott · Accepted solution]

For anyone interested, the good folks on the Atlassian Connect team were able to assist in determining the root cause of the problem.

When installing add-ons in Confluence Cloud, a separate user account is created for each add-on.  By default, these add-on users accounts belong to the confluence-users group.

When the add-on server makes a call back to the host Confluence application's REST API (e.g. in my case, to fetch the macro body), it authenticates using the add-on's user account in the host application.

// This call from the add-on server to the host application will authenticate using the add-on user account
 
addon.httpClient(req).get({
  uri: "/rest/api/content/1/history/1/macro/id/2"
}, (error, response, macroBody) => {
  ...
}

If the Space permissions don't grant View access to the add-on user; any attempt to fetch the macro content will fail.  (This explains why many users were not having this issue, because the default Space permissions include confluence-users).

The solution is to use the Javascript API to fetch the macro content from within the rendered add-on's <iframe>;  as these calls from the browser to the host application are authenticated using the current user. 

// This call from the add-on iframe in the browser to the host application will authenticate using the current user account
 
AP.require('request', function(request){
	request({
		url: "/rest/api/content/1/history/1/macro/id/2",
		type: 'GET',
		contentType: 'application/json',
		success: (response){
			...
		}
	});
});

[Joao Correia]

Hi! I was facing the same problem, but if you give view access to confluence-users on all spaces means ALL people in your Atlassian instance will be able to see those spaces. 

I use spaces for each client, and I do not want people to see each other spaces, so I create dedicated groups for each client, remove the access confluence-users from each space and provide the group for that client.

Am I doing something wrong here? Seems weird for the addon to require permissions from a group where is everybody.

Thanks
Joao

[Tim]

Hi Scott,

The only reasons I've come across have been:

1. Page restrictions where the add-on user doesn't have access
2. Preview mode limitations: can't access the macro body until the page is saved
   https://ecosystem.atlassian.net/browse/CE-85

Have they double checked if their page has any restrictions?

[Scott]

Thanks Tim.

Yes, I asked them to check for page restrictions, and they confirmed that there were none.

Preview is OK, because my add-on specifically skips the fetching the macro body when outputType=preview  (I display a message instead saying that the add-on won't render until the page is saved).

I can see in my logs that the preview requests are returning 200 OK, and it is only the outputType=display ones (for this user only) that are 404'ing.