Forge GDPR, custom UI methods in Confluence, and app context security documentation

[iceman]

ADDED - Forge support for GDPR

As part of Forge’s Developer Terms and Conditions, any app that declares it stores personal data must integrate into the Atlassian GDPR flow as documented here. App developers must ensure their app meets these requirements prior to being listed on Marketplace.

A reportPersonalData method has been added to @forge/api to help apps comply with Atlassian GDPR requirements. See Privacy API for more details and examples.

Run npm install @forge/api@latest in your app directory on the command line to install the latest version of Forge API.

Learn more about GDPR for Forge.

ADDED - Navigate and open methods for custom UI apps in Confluence

Custom UI in Confluence now supports navigating to external links with the existing router object exported from the @forge/bridge package. See custom UI bridge for more details and examples.

Run npm install @forge/bridge@latest in your resource directory to update to the latest version.

ADDED - App context security documentation

We’ve added app context security documentation to help app developers understand how to use the contextual information passed to their app securely.

[tobitheo]

Thanks for these announcement posts, they really are very helpful!

I do have two questions for this one though:

1. Is it possible, at this point, to securely know e.g. which page a Confluence macro is being viewed on right now?
2. For reporting personal data, I think it would make most sense to use a scheduled trigger. Am I correct in that assumption and if so: The schedules trigger imposes some restrictions on installations that would make Marketplace distribution kind of awkward due to the 100 app installs maximum.

Thanks,
Tobias

[sopel]

@tobitheo

For reporting personal data, I think it would make most sense to use a scheduled trigger. Am I correct in that assumption and if so: The schedules trigger imposes some restrictions on installations that would make Marketplace distribution kind of awkward due to the 100 app installs maximum.

Indeed, the docs even provide a (not yet accessible) sample implementation for this approach:

Forge includes the ability to schedule work at regular intervals using scheduled triggers. In the example above, we combine both a weekly and an hourly schedule to implement the flow.

To help partners comply with GDPR requirements, could you please:

1. Make Bitbucket publicly accessible?
2. Provide a roadmap/ETA update on the “new version of scheduled triggers which should support much more than 100 installations and have more scheduling options” as per [FRGE-124] - Ecosystem Jira

Thanks,
Steffen

[sopel]

Thanks for the docs update regarding App context security and the resp. shared responsibility model contract - I’d appreciate a clarification on why cloudId is not “guaranteed to be secure”, but let’s discuss this potentially more complex topic via App context security and tenant isolation guidance for separation of concerns.

[shraj]

1. Yep, the repository should now be publicly accessible
2. We’ve been actively working on improving Scheduled Triggers to meet this exact use case - by next week, that 100 installation limit should be removed.

Is it possible, at this point, to securely know e.g. which page a Confluence macro is being viewed on right now?

I believe there should be a contentId as part of the Product Context that gets passed in (via useProductContext()) to the Forge lambda. However I’m happy to investigate further if that’s not what you’re after

[tobitheo]

@shraj Sorry for the late reply. The contentId is indeed available, but if it cannot be trusted (as indicated by the documentation you linked), then we cannot use it for anything security-sensitive like returning app data linked to that content.

[shraj]

From my understanding of this and this - we’re simply stating that it may be possible for a bad actor to tamper with the request (e.g. changing the contentId via the DevConsole), which in turn may cause your app to return more data than it should to the end user.

The recommendation, particularly for security sensitive use cases, is to explicitly verify that data - for example, verifying that the supplied accountId actually has the permissions to view the supplied contentId, if you’re surfacing additional information that should only be available to users with access to that page.