How can I call the Confluence API for a different Atlassian site from a Forge app?

Confluence Development Confluence Cloud
,
1

I’m building an app that displays information about a selection of Confluence pages, using a dev site for development. That worked fine for examining the pages on the dev site, but now I want to do more thorough testing using metadata from older Confluence pages on my real site (which has many more pages and history). Forge’s built-in auth makes it easy to call the Confluence API for the site I’m on, but how can I call the Confluence API for a different site?

Ideas I’ve had so far:

  • Pass the full URL into requestConfluence instead of just the endpoint. This gets munged by the route template function.
  • Pass the full URL into api.asUser().requestConfluence(assumeTrustedRoute()). This works but gets a 404 response, perhaps because the app isn’t authed to the other site (even though I, the user, am).
  • Use fetch with basic auth to call the API directly. This gets blocked by CORS, which is fair enough, that’s what it’s for.
  • Add OAuth parameters to the manifest and authenticate to the other site that way. I can try this, but it’s very complicated for something that’s only needed for development and testing, so I’d rather not if I can avoid it.
  • Mock up some test data and serve it directly (or hardcode it). I’ll fall back to this if I have to, but it would bypass a lot of app logic so it’s not very good for testing.

Is there a more straightforward way to do this that I’m missing?

Alternatively, is there a way to create pages with fake (past) edit dates so I can fill my dev space with the kind of data I want to test on?

2

Welcome to the Atlassian developer community @FinnEllis,

I’m not sure I understand the use case. Why can’t you install the app into the production environment? Or, better yet a sandbox? Testing seems like a poor reason to “swim upstream” against the Forge model. There are some solutions to cross-site apps for Forge, but they are intentionally hard, so that apps are secure by design.

3

Oh I’m absolutely open to a better development flow as well. I haven’t installed the app on the production site yet because it provides a space page, so (I think?) it will be visible in the sidebar for everyone, and the app isn’t ready for that yet. Is there a way I can develop on the production site without everyone else being able to see it before it’s ready?

We’re on a Standard subscription, so it looks like a sandbox isn’t an option.

4

@FinnEllis,

Good reasons. You aren’t missing anything. There isn’t any good way to suppress UI from an App based on your dev work.

I think you could still operate on your set of data by doing a site export, then import on your test site. If you haven’t already, make sure to get your dev instance from this link go/cloud-dev. I wouldn’t want your work to be limited by the operational constraints of our free edition.

1 Like
5

Hmm, exporting might work although I’m not sure if it will include the right set of data – I need version history (at least the most recent version), and I don’t want to add users although I suppose I can just delete them again.

I think I did use that link to get the dev site, if it’s the same one I would have found in the Forge getting started materials.

I’ll give this a try and report back. Thanks!

6

Looks like that worked! Not 100% positive because I have other things in the app to debug, but I can at least see that the import preserved the edit time which is what I needed. Thanks!

1 Like