We need to extend the scopes required by our Confluence Cloud app, and AFAIK all our existing customer will need to approve this update on their cloud instances manually.
We don’t expect all our customers will approve this update quickly or even approve it at all. The problem with it that we can’t deliver descriptor updates to such customers after new version with extended scopes set will be released. It might be required if we add a new module (which works with both sets of scopes) or need to refactor backend endpoints.
Is it possible to maintain two versions of descriptors for both sets of scopes? Is there any workaround if the straight way doesn’t exist?
First way is to version your urls. Ie have all of your api calls be nested under a version “folder”. Thus /page becomes /1/page. You can then append the version to the base url in the descriptor. You’ll need to continue serving the old url for a while (until you see the traffic die off). Now the functionally might not change within the endpoints - you’ll just know what the capabilities are from the installation based on the path. The biggest benefit of this approach is that you’ll just need to update the descriptor in a single place (the baseurl).
The second way is to add it to the query string. This will allow you to pass in capabilities directly from the descriptor to the end point (basically a form of feature flags).
There are probably other ways of doing it but hopefully that helps.
Thank you for the suggestion! Do you know whether it is possible to update descriptors for those users who haven’t approved the required scopes set extension?
You can’t force anyone to update the descriptor but you can detect it(either through what I mentioned or other strategies) and then advise the users through the ui to update (or get their admin to update).
I mean whether it is possible to maintain two parallel versions of descriptors (and updating them in parallel as well) - for those who approved new permissions and for those who don’t?
