Background:
We are considering partially porting our app to Forge, bit by bit and would use Connect on Forge for that. We do want to get something out of Forge, otherwise it is not worth the effort.
The thing we want most is using Forge storage, for two reasons:
To get data residency
To not store any costumer data.
So, we want to replace all of our storage with Forge storage, and this includes the Connect installation records, sent via Connect installation record.
I’ve found that for forge remotes, you can enable the `appSystemToken.enable’ property, that then adds the ‘X-Forge-Oauth-System’ header that then can be used to access the Forge storage (I didn’t test, assumption from docs).
However, for connect modules there is no way to get such a ‘X-Forge-Oauth-System’ to authenticate to the forge storage.
That means all ‘Connect’ modules have no ‘direct’ way to access the forge storage for a request. The Connect requests do get the classing JWT token.
What we need: A way that a Connect module invocation is able to access to Forge storage.
Assuming the Connect module is stateless and has no storage.
So, my questions:
Is it possible to access the Forge storage via the JWT token used by Connect?
Or some other way a Connect backend can call to the Forge storage.
RFC-34 isn’t a solution (and closed). The see later discussions below.
Ah…thanks. I’ve forgot about that RFC…I’ve to read it and think about it.
Update: RFC-34 is closed. And it probably would not work. Because it start of with requiring a appSystemToken already to get hold of the long term token.
However, the thing we want is that the Forge Connect can rely solely on Forge for any long term state. Assume the Connect endpoint just restarted and has a black state. The Connect endpoint will the a request with a ‘Connect JWT’ token => The state it requires to continue is in Forge storage.
So, how does it go from ‘Connect JWT’ to authenticate against Forge storage?
If we have to keep our own Storage on the Connect side for some long term tokens, then the main benefit of Forge for us evaporates: Because then we still have to maintain a storage which holds secrets. So, we might as well continue with being a Connect only app.
Interractions with Forge Storage is only available via Forge Remote and cannot be accessed by JWT.
An offline solution will be coming soon, which will allow you to have long running offline access to Forge via Forge Remote. This will be supported in Atlassian Connect Express and Atlassian Connect Spring Boot, similar to the exisiting implementation of Forge Remote in these frameworks.
An offline solution will be coming soon, which will allow you to have long running offline access to Forge via Forge Remote. This will be supported in Atlassian Connect Express and Atlassian Connect Spring Boot, similar to the exisiting implementation of Forge Remote in these frameworks.
I’m curious about that. The big thing for is if that solution will require a persistent storage on our side for us. We certainly are willing to cache things for many hours. However, we need a path to recover from zero without persistence.
Otherwise we probably will delay Forge adoption further. As removal of having a persistent storage on our side is the main benefit we would get at the moment.
Update: In theory we could use a webtrigger to do an initial Forge Auth token. However:
The webtrigger URL must be predictable OR the information of its URL must to be accessible via endpoint that accepts the Connect JWT token. Note that that adds an additional roundtrip.
Predictable webtrigger URLs is way better, as a rountrip to an API is another point of failure and latency source.
The performance of web-triggers seems abysmal. It’s seems at least 1 second. (1.4 from EU, 1 seconds US). The Forge Storage access alone is ~100ms within the web-trigger.
So, that isn’t a great user experience: The app would once in a while look stuck, spinning its wheel.