Forge app integrating with self-hosted software

[RhiannonGray]

G’day all.

Hoping someone (maybe from Atlassian, maybe just someone with experience navigating the ecosystem) can give me a hand here.

The company I work for develops software which customers host themselves on their own domain. We’ve had a number of potential customers interested in using Atlassian products (primarily Confluence and Jira) with our software, and would like to be able to support this. In my testing, I’ve found Forge quite suitable for our purposes - responding to page events, updating content, etc. We’ve got a working proof-of-concept app that functions well, and would like to start demos for customers.

Unfortunately, because our customers each use their own servers, it is not possible for us to declare the egress URLs in the app manifest ahead of time - they’re outside of our control. In a perfect world, we’d have a text field in our Forge app settings page that points to the customer’s server and the backend can just fetch() from whatever is configured there. This obviously won’t work with Forge’s security controls (fair enough! arbitrary egress is generally bad). The workaround I’ve come up with is to have custom versions of our app built for each customer, setting different egress URLs and app IDs in each copy’s manifest. This is far from ideal, since it means any updates to the core code have to be replicated across each individual copy, which will become increasingly laborious the more customers we have using Atlassian products. I can also foresee an awful mess of versioning problems depending on how RFC-106 goes. Unless I’m missing something though, there’s no way to set a blanket “accept” for external fetch() URLs in the manifest by design, so we’re a little bit stuck with that as our best option.

My questions are:

• Is there a better way to do this that I’m not seeing?

• How would we go about distributing this? I’m guessing based on the Forge guide that distribution via the console is the best approach, but confirmation from someone who knows what they’re doing would be good.

• If we do distribute this as described, will we be breaking any Atlassian T&Cs? We do not intend to monetise the Forge app, since it’s only useful in combination with our software.

[nathanwaters]

RFC-94: Configurable Egress and Remotes

RFCs are a way for Atlassian to share what we’re working on with our valued developer community. It’s a document for building shared understanding of a topic. It expresses a technical solution, but can also communicate how it should be built or even document standards. The most important aspect of an RFC is that a written specification facilitates feedback and drives consensus. It is not a tool for approving or committing to ideas, but more so a collaborative practice to shape an idea and to fi…

[EckhardMaass]

Hello,

I know its not ideal to open up all egress, but have you tried a wildcard like this

    fetch:
      client:
        - '*'

…it works for us making calls from the front end. And then have paranoid controls where we make sure we use only configured URLs.

Best,
Eckhard

[RhiannonGray]

Ah, I thought there might be something along those lines - this looks ideal. Do you know if this has been implemented yet, and if so, where it would be documented?

@EckhardMaass

I know its not ideal to open up all egress, but have you tried a wildcard like this…

To be completely honest, I hadn’t tried it - and it worked perfectly! I’m not sure how I missed it, but it’s even explicitly mentioned in the manifest permissions documentation as an option.

Thanks!