07 Sep 2021 - Forge CLI version 2.0.1 and Secure Storage API

:tada: ADDED - linter support for the connectModules property to the Forge CLI

To help support developers moving Connect apps to Forge, we have added linter support for the connectModules property to the Forge CLI.

:tada: ADDED - Forge Secure Storage API in @forge/api 2.3.0

We’re adding new APIs to the existing Forge Storage API so that Forge apps now store secrets and credentials securely.

Similar to storage.set, storage.get and storage.delete, the new APIs are storage.setSecret, storage.getSecret, and storage.deleteSecret.

:tada: ADDED - Submit method to the view export of @forge/bridge 2.1.0

Added a submit method to the view export of the @forge/bridge package to enable form submission. The method is supported in Jira custom field edit, Jira custom field type edit, and Jira context configuration.

:tada: ADDED - Custom UI support for Jira custom field edit

Added Custom UI support for defining the editing experience for Jira custom fields and Jira custom field types.

:tada: ADDED - Custom UI support for Jira context configuration of custom fields

Added Custom UI support for Jira context configuration of custom fields.

:wrench: UPDATED - Forge CLI install upgrade warning

We’ve modified the forge install --upgrade warning to communicate specifically when the upgrade requirement is caused by permission changes.



From the docs it looks like storage.x behaves exactly the same as storage.xSecret. Other than the secret version being encrypted (I assume) is there any reason why I should use the non-secret version anymore now? Am I doing something wrong if I store all my “normal” data via the new method? What are the implications? It would be nice if you could add some documentation regarding this. :slight_smile:



Hey Sven,

Thanks for posting. The secret APIs on storage is specifically meant to store secrets. While nothing is stopping us from using it to store general-purpose data today, in the future, we are looking at adding features into this API that is meant only for secrets like API keys. Which may impact the app if there are general-purpose data being stored in secret storage.




I had connect on forge App working on v1.6.1
However after updating the forge-cli to version 2.0.1 , the connect modules are not getting displayed, although the App is getting installed without any issues after I add the below lines in the App manifest

    key: app-key
    remote: connect

Are there any issues with Forge CLI v2.0.1 with Connect on forge ?

Hi @ajay

I will look into your connect-on-forge issue tomorrow.


1 Like

Hi @amathur,

thanks for your answer! While I appreciate your response, I’ll have to tell you that it didn’t really answer my question at the level of detail I was hoping for.

Of course, I personally understand that I shouldn’t be storing my non-sensitive data using the new secrets API, but there may be many who don’t. (i.e.: If you don’t make it 100% clear why developers shouldn’t do this, you’ll likely see some doing this very soon) It would be great if you could add at least some high-level information to the documentation about what functionality you expect to build here and in what explicit way, shape, or form apps will be impacted by this functionality if they store non-sensitive data using this API.



Who has access to storage.set data at the moment and how does storage.setSecret make sure they dont have access anymore?


Is it possible to get the forge/api version listed when things are added to it?

1 Like

Hi @jhazelwood

Let me know if you need my manifiest or atlassian-connect to debug the issue…
With cli 1.6.1, the app key would be appended with a UUID , but with the latest release 2.0.1, I dont see that happening… Not sure if its related to the issue I am facing… The forge install works , and I see the connect App also installed in the cloud instance… but the UI modules ( in my case web-items in jira.software.board.tools ) is missing

We’ve reproduced the missing modules issue and are investigating it now. You can follow this ticket for updates.


@jhazelwood Thanks for the info… I will wait for the fix… ( have a Codegeist entry to be submitted :wink: )

Hey @MWulff,

It is more about the difference in the purpose of the two APIs. The secrets API on storage is meant to store secrets and in the future, we will be adding features to this API that are meant only for storing secrets like, API keys. To enhance security stories around them. For example, currently, the secrets stored using storage.setSecret are not queried when running storage.query API.


1 Like

Please see the public issue for an update. It includes a workaround, which is to let us know your app ID so we can let you know your app’s randomly-generated key, in order to set app.connect.key to match.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.