Rate this page:
This page includes release notes and updates for Confluence Cloud app developers. Use this page to keep track of upcoming changes, deprecation notices, new features, and feature updates from Confluence Cloud.
For updates about changes to the Forge platform, see the Forge changelog in the Forge documentation.
You can also ask questions and learn from other Confluence Cloud developers on the Atlassian Developer Community.
The license
object returned by view.getContext()
in Custom UI and useProductContext()
in UI Kit now returns additional properties with relevant license information. This is only present for paid apps in the production environment. More details of what is accessible from the license object can be found here.
Two fields that were previously only available through an API call are now available through the /installed
lifecycle event. From today the /installed
lifecycle event will return with 2 additional fields: entitlementId
and entitlementNumber
where available. For documentation on this event, see this page.
Rollout: progressive rollout by tenant. in progress
The table node (ADF) now supports an optional width attribute that determines the overall width of the table container, this attribute is only interpreted for pages (not comments, etc.).
This value is interpreted separately from the tables' column widths (if present) and should be an integer. This functionality supersedes the current layout
attribute and is backward compatible. More information on the ADF definition of the table node can be found here.
The following headers have been added to all deprecated V1 REST APIs
Warning: 299 - "Deprecated API"
Deprecation: <date of deprecation here>
Link: <link to changelog entry here;> rel="deprecation"
The deprecation headers are enabled for the Ecosystem beta group, and will be rolled out progressively to all of production in the next week.
The route
template function (used to access Atlassian product APIs) now blocks more potentially malicious user input; this helps prevent vulnerabilities like path traversal in Forge apps. We’ve implemented this enhanced security through additional checks that only apply to the path segment of the URLs being constructed (not query strings).
If you are sure the input is legitimate and cannot lead to an unexpected API call, you can encode it manually or use assumeTrustedRoute
.
In October 2023, Atlassian plans to add support for Canada to Connect apps, alongside existing data residency regions available to customers. Once this region is available, we will be updating our data residency supported region keys to include Canada (CA) alongside our existing supported data residency regions. We will provide further updates closer to availability.
As a reminder, if you indicate support for a realm, it means your app stores the relevant data that is in-scope for your app’s data residency solution (see Atlassian’s documentation on in-scope data for our products here). For more information, please refer to the Connect data residency documentation.
In addition to Canada, Atlassian is exploring making additional data residency regions available in the future. These can be identified on the Atlassian Cloud Roadmap and we will provide similar updates/notice prior to these regions being available.
We have added a new isSpaceAdmin
display condition for Confluence. Now you can display your app modules only for space admins. This is available only for modules that are registered on space and page level.
See the display conditions for Confluence reference documentation for more details.
Support for atlassian-connect-spring-boot 3.x will end on 18 November 2023.
Apps must migrate to atlassian-connect-spring-boot 4.x during this period.
We have released a Spring Boot 3.x compatible version for Atlassian Connect Spring Boot (ACSB 4.x). To continue to be supported, please upgrade by November 18 2023.
With this release, you can start to migrate apps to ACSB 4 and Spring Boot 3.
This release includes these updates:
Migration to Spring Boot 3.1.0.
Migration to Java 17.
The previous 2.7.x version of Spring Boot is reaching End Of Life (EOL) by November 18th 2023 (Spring Boot).
As per Understanding JWT for Connect apps and our previous deprecation notice, the Jira and Confluence APIs now only allow Connect apps to provide authentication JWTs as an Authorization: JWT
header in requests. the Atlassian Jira and Confluence APIs will no longer inspect the ?jwt=
query string parameter and requests for all apps, and consequently may fail with a HTTP 401 response.
Please utilise the JWT auth header as a means to authenticate as outlined in: https://developer.atlassian.com/cloud/jira/platform/understanding-jwt-for-connect-apps/#creating-a-jwt-token
This change does not affect how Jira or Confluence provides the Atlassian product JWTs to Connect app modules/iframes.
Please note: This removal will progressive rollout by tenants, increasing to 100% by the 15th September, 2023
Accepting sensitive JWTs as a query string parameter presents a problem as the query string is often saved in web browser history, passed through Referers to other web sites, stored in web logs such as intermediate proxy servers.
If your app provides its Connect JWT to the Atlassian APIs as a query string parameter, you must update it to pass the JWT via an Authorization: JWT
header.
We have now added Inline
and Stack
components in UI Kit 2. With these new layout components, you can easily organize your components either horizontally (Inline
) or vertically (Stack
).
For more information on how these components can be used with examples, see Inline and Stack documentation.
Run npm install @forge/react@latest --save
on the command line to install the latest version of the @forge/react
package.
We have begun using 4 new security scanners for Connect security requirements on the Atlassian Marketplace. The new scanners will be used to check your Connect apps for:
Signed Install Authentication (Req 1.4)
Authorization (Req 1.2)
Input Validation (Cross-Site Scripting) (Req 8)
Insecure Storage of Secrets (Req 5)
See our announcement for new scans enabled on Connect apps: https://atlassianpartners.atlassian.net/l/cp/Xki0k1Pp
As always, we will notify you of any apps that are found to be missing security requirements via the Atlassian Marketplace Security Jira Project. As a reminder, all apps are subject to the Security Bug Fix Policy for Marketplace apps and must respond to reports of missing security requests in a timely manner.
If you’d like to check your apps yourself, or scan any new apps before listing them on the Marketplace, you can use open sourced versions of these new scanners using the documentation at CSRT and Connect Vulnerability Scanner repositories.
We have added the following predefined Confluence Connect Conditions:
user_is_anonymous
- checks whether the current user is anonymous
user_is_licensed
- checks whether the current user is licensed to use Confluence
These conditions are now listed here.
Prepare for Atlassian’s latest Connect app security scanners with new open source scanners for Signed-install AuthN, AuthZ, Input validation(XSS), and Insecure storage of secrets.
Atlassian regularly releases new cloud app security requirements and scanners to increase the baseline of security across all cloud apps and protect our shared customers from security risks.
Don’t get caught missing a requirement! Prepare for Atlassian’s latest Connect app security scanners with new open sourced scanners for Signed-install AuthN, AuthZ, Input validation(XSS), and Insecure storage of secrets.
Should we find a missing requirement, we will notify you via the Atlassian Marketplace Security Jira Project. As a reminder, all apps are subject to the Security Bug Fix Policy for Marketplace apps and must respond to reports of missing security requests in a timely manner.
Marketplace Partners with access to the Partner Portal can find the new scanners and more information here in the Partner Portal.
We’re opening a 9-month deprecation period where a handful of write-operations will end support for using groupName
parameters in favor of utilizing groupId
parameters. Additionally, a small collection of endpoints utilizing groupName
with already-existing groupId
equivalent endpoints will be deprecated, and finally, a large number of read endpoints have been updated to respond with both a groupName
and groupId
, rather than simply a groupName
.
These changes are a follow-up to our previous changelog post #1050, where a collection of group-based endpoints were deprecated in favor of groupId
equivalents. These changes are the same in purpose: Supporting the group renaming functionality described in https://community.atlassian.com/t5/Atlassian-Access-articles/Org-admins-can-now-rename-groups-in-cloud/ba-p/2276321.
The anticipated deprecation date of the group name-based endpoints & parameters is May 1st, 2024.
What exactly is changing?
We have a small collection of endpoints in the Content Restrictions section of the API that are being deprecated entirely in favor of equivalent endpoints that are already available and identical in behavior; these endpoints simply consume a groupId
path parameter, rather than a groupName
path parameter like the now-deprecated endpoints. The endpoints being deprecated are as follows:
In addition, a collection of write-based endpoints consuming groupName
in some capacity are being updated to support groupId
as well (if not already), and a deprecation notice is being applied to their respective groupName
fields, where applicable. Behavior for all these endpoints will remain the same, but within the 9-month deprecation window, migration to utilizing groupId
rather than groupName
will be required. The endpoints being updated to deprecate groupName
usage are as follows:
Update content restrictions - input groups now accept a groupId
, and groupName
is marked as deprecated
Add content restrictions - input groups now accept a groupId
, and groupName
is marked as deprecated
Add new permission to space - input groups currently accept both a groupName
or groupId
value in the identifier
field; in 9 months this field will only service groupId
values.
Add new custom content permission to space - input groups currently accept both a groupName
or groupId
value in the identifier
field; in 9 months this field will only service groupId
values.
Create space - input groups associated with permissions now accept a groupId
, and groupName
is marked as deprecated.
Lastly, a collection of read endpoints currently only returning a groupName
have been updated as of this announcement to also return groupId
in the response payload. No action is required here, but using the additional returned information may be useful for some of the other described migrations. The endpoints being uploaded to include a groupId
in the group object of their response body are as follows:
What action is required of me?
The following table presents a mapping for the 3 deprecated endpoints to their logical equivalent that utilizes groupId
rather than groupName
:
APIs to be removed on May 1, 2024 | APIs to switch to before May 1, 2024 |
---|---|
Get content restriction status for group - | Get content restriction status for group by groupId - |
Add group to content restriction - | Add group to content restriction by groupId - |
Remove group from content restriction - | Remove group from content restriction by groupId - |
For update content restrictions and add content restrictions, content permissions being added/updated that are associated with groups must begin passing a groupId value in the id
field. For programmatic groupId
retrieval (getting the groupId
for a given groupName
) , we recommend you use the Search groups by partial query endpoint, and parse the response body for the necessary groupId
value(s) to then pass in the groupId
based endpoints/parameters.
GET
/wiki/rest/api/group/picker
Search groups by partial query consumes a query
string parameter and searches by substring. This is a more powerful search functionality but can also be used to reflect a simple Get group by name
functionality if you simply pass the full name of the group you’re looking for my name.
This endpoint guarantees safe behavior, as if the group you’re looking for has been renamed, it’ll be missing from the search results. Using this endpoint as the gateway to retrieving an immutable groupId
to use in other endpoints will protect you from “missing” groups in the post-group renaming world.
For add new permission to space and add new custom content permission to space, the same strategy as above is recommended in order to retrieve a groupId
to pass in place of a groupName
. The only difference here is that the aforementioned endpoints will accept the groupId
value in the existing identifier
field. Remember, identifier
will stop accepting groupName
values as of May 1st 2024.
For create space, the same strategy for groupId
retrieval described above is recommended. If you’re creating non-default space permissions upon space creation associated with groups, begin passing a groupId
value in the id
field.
Lastly, for the many endpoints being updated to include a groupId
in their response body id
field, no action is required on your end - we will continue returning groupName
as well. The heart of these changes is to protect the end user from dangerous behavior - aka making write-based calls contingent on the name of a group, a mutable field. As such, there is no harm in getting the current name of a group back at any given point in time in a post-group renaming world.