Niel here, Associate Product Management Intern at Atlassian.
My team is working on some new improvements to web triggers in Forge. We’re aiming to make sure all apps with web triggers have a path to our Runs on Atlassian (RoA) badge.
Quick reminder, Runs on Atlassian is a Marketplace badge designed to help customers identify apps that a) do not transmit data outside of the Atlassian Cloud and b) provide data residency.
Keen to meet with Forge developers who have apps with web triggers, or developers who are planning to use web triggers, to better understand use cases.
I would love to hear about:
What sort of data is being sent
Why this data is important to the app
The impact some of our ideas might have on these apps
I’m happy to chat either here in this thread, or you can schedule some time with me to chat on Zoom: Forge Web Trigger Chat
our app is based in Jira Cloud. We could need WebTriggers to somehow offer an external API to read/write entities into Forge store, trigger internal app updates or update values in Forge Custom Fields just because there is no other way for customers to send or update data from automation external systems even a DC migration requires somehow an update request in our app. What I personally don’t like at all, is the fact, that WebTriggers are open to anyone. The vendor has to implement their own authentication. I would at least like to require the normal Atlassian authentication and would like Atlassian to take care of all authentication within Forge even for WebTriggers as an “external API”. This would help us a lot more and allow us to offer proper APIs in some way.
Hi @Niel-Reitmann ,
I hope this message finds you well. I’d like to clarify how Forge web triggers relate to RoA. Please don’t misunderstand me - I’m simply looking to understand this relationship better.
As I see it, web triggers provide content that is strictly defined in the permissions section of the manifest.yml. If an app doesn’t facilitate data egress, the web trigger wouldn’t be able to send any information to a third party. Essentially, a web trigger acts as a type of invocation function, callable not only from the front-end but also from other applications. Naturally, the web trigger can only return data that the app has access to and that has been explicitly prepared by the developer.
Many apps actively use web triggers for a variety of purposes. Two of the most popular use cases are:
Cross-application communication:
Web triggers are often used to send messages between apps, including cross-application scenarios. Currently, there aren’t any direct alternatives to this functionality. Perhaps, in the future, we’ll have something like cross-app events or listeners, but for now, this capability is still under development.
REST-like endpoints:
Web triggers can serve as REST-like endpoints, facilitating communication between external users or applications and the content within our app.
I hope this sheds some light on how Forge web triggers operate and their significance. Let me know if you’d like to discuss this further or need more details!
We are exploring ways to allow web triggers to accept data into the app without allowing it to return data out. This should satisfy the use case of needing to migrate data into the Cloud app from a D/C deployment.
Providing a built-in authentication mechanism for web triggers is a great suggestion, thank you.
Would you expect this to work with standard Atlassian account authentication (eg. user-generated API tokens)?
While web triggers are not currently part of the egress permissions for a Forge app, a web trigger could still potentially be used to egress customer data out of their site without their knowledge.
This is the issue we are exploring how to address and helps us stay aligned with the Runs on Atlassian concept.
We are working on providing new capabilities that would allow some web trigger use cases to more closely match the customer expectations regarding apps with RoA status.
We currently use web triggers to allow our Connect hosting infrastructure to speak to a companion Forge app to share configuration/trigger actions that must be run on Forge in order to access REST APIs or Forge Storage.
Even once those two are merged into the same app, we need to be able to expose our own “REST API” implemented in Forge functions, to other parts of the app that may not be natively hosted on Forge.
Customers ask us for publicly available and documented and secured REST APIs for managing their user-generated content within the app using their own processes and tooling, rather than our web UI within the product within Jira/Confluence. Web triggers is the only option for this in a Forge native world.
I echo @lkimmel’s point that web triggers need a built-in authentication mechanism.
Thanks,
Jon
Yes, user tokens or even Forge request API tokens would be nice. That way, also a cross app communication could happen. Just having endpoints to only consume data is already a first step but some customers would also like to read our data that is stored in Forge storage in some way, which we cannot provide at the moment.
External oauth generically would be nice. We’d prefer to use that for communication with our app. But FIT has been working well! We are using wetriggers to push data, but I was wondering what the best practices are for using an auth header to make that more secure?
Thanks!
Can you share some more details on how a Forge app REST-API GET endpoint equivalent can be implemented with web-triggers while still qualifying for the “RoA” badge?
