Environment variables and app distribution

I have an app that makes authenticated REST API calls to another product. As such, it requires a bit of configuration, most of which is supplied through an AdminPage and stored via the StorageAPI. However, in following Atlassian’s recommendations for security, the app relies on being able to access the client secret value as an encrypted environment variable.

This has worked flawlessly through the development and testing stages, but on the first attempt to install the app in a customer instance (shared via Installation Link from the Developer Console) we found that they aren’t able to set environment variables for their instance / environments using the Forge CLI.

Did we miss something? Surely there is some way for them to set their own environment variables, right? Or is there some way I can set them programmatically from the app itself - that way I could collect that value via the AdminPage as well but have it stored as an env var rather than in StorageAPI?

For reference, even attempting to list environment variables, they would get errors like this:

Error: Server error: [{“message”:“Permission denied”,“locations”:[{“line”:2,“column”:3}],“path”:[“installationsByAppEnvironment”],“extensions”:{“errorSource”:“UNDERLYING_SERVICE”,“statusCode”:400,“errorType”:“UNAUTHORIZED_TO_MANAGE_APP_ENVIRONMENTS”,“errorDetails”:{“code”:“UNAUTHORIZED_TO_MANAGE_APP_ENVIRONMENTS”,“message”:“Permission denied”},“classification”:“DataFetchingException”}}], requestId=6a0e9c09f613342e

2 Likes

Perhaps a different line of questioning will trigger a response. :wink:

So along those lines, is anyone else doing something similar - storing/using a piece of sensitive information that would need to differ for each deployment of your app. If so, how are you going about it?

Any news on this Atlassian?

FWIW, I ended up having to go against recommended approach and leverage the Storage API to store my OAuth secret. I did take some steps to mitigate risk though:

  • The value is encrypted before being stored
  • The value is only decrypted at the point it is actually injected into the API call
  • This decryption and (external) API call happens server-side (in a webtrigger) rather than on the client

Because of the above - and the seeming lack of any other way to get around the current limitation :frowning: - I felt pretty comfortable proceeding with the use of the Storage API. I’m sure there are some things I’m not considering, but from the outside looking in, I think a similar ‘encrypted’ flag to what exists for environment variables would be a perfect addition to the Storage API. The API wouldn’t even have to expose the unencrypted value directly as it could provide a util call to handle that, further mitigating the risk of exposing sensitive data. At the end of the day though, I think it comes down to the individual developers making the right choices around security and having a platform that simply provides the tools to do it. :wink:

2 Likes