We just added user property APIs in Confluence Cloud

Hi developer community, in response to a highly voted customer ask, we are releasing a new set of APIs, namely the User property APIs. Please have a look at the changelog for details.

7 Likes

This sounds particularly useful for cases where we have been previously using AP.cookie before to store user preferences such as view mode, tracking preferences and bookmarks/watches, but now we can ensure that they are persisted permanently rather than just in one particular browser.

I’m wondering about two things:

  • Who can access the user properties? From the docs it sounds like anyone who can access the Confluence instance can access them. This would be a privacy concern for many potential use cases.
  • What does this mean: “Furthermore, we are ensuring properties stay isolated amongst different developer apps.”? Does it mean that individual apps cannot access user properties created by another app? Or just not the ones by other app vendors? How exactly is this isolation ensured?
2 Likes

Thanks so much for your Q. @candid . I’m glad this persistence rather than just 1 particular browser is gonna be valuable to app vendors.

-Anyone can access app properties APIs per say but can read/update/delete only those user properties created by them so there isn’t a privacy concern here.
-Yes individual apps can’t access user properties created by any other app. So that would mean 2 apps belonging to same app vendor can’t access user properties created by each other either. We did this isolation at app level to ensure no information sharing across apps and support our vendor’s use cases at an individual app level. In terms of API usage, this would mean two apps a1 and a2 can store the same key (value could be different) for a user and for confluence as a product, they are two separate user properties.

Thanks

1 Like

Thank you, this sounds really good.

1 Like

Can you clarify what the availability of this API is from Forge? Because I’m very confused by the documentation here:
The API docs provide Forge example code but also say in the example code that this API is not supported via OAuth 2, which is required for Forge as far as I know. Also doesn’t list what scopes would be required in Forge apps, so I just assume this is not supported via Forge at the moment?

I gave it a try but the API didn’t behave as I expected after reading this part

can read/update/delete only those user properties created by them

Well, could of course mean I misunderstood it :wink:

So what I did: I created a user property with “user x” for “user x”. Then after logging in with “user z” I was able to read, update and delete the previously created user property. My understanding was that none of these operations should have been possible.

However, if the observed behavior is intended then I’m not sure if the feature really adds value. Storing some user specific data could already be achieved with an app property and encoding the user identifier in the property key.

We will be adding granular OAuth 2.0 /forge scopes soon to this API. Thanks

@RonnyWinkler Hi. Can you share more information on how exactly the property was created? Basic auth/Connect app (as app or as user), or any information like the tenantid.

Right now, all user properties are isolated at the app level, so an app cannot access another apps properties (unlike app properties). But an app can access all of its user properties (regardless of whether its calling it asApp or asUser impersonation). So its very much possible to perform CRUD on userA by the app when logged in as userB.

Can you share your concerns about this behavior? We’d love your feedback, and can consider adding restrictions.

@JatinChopra thanks for the feedback.
Some context: all operations have been done via the browser dev tools from within a Connect iframe using AP.request. The creation, modification and deletion have all been executed from the same Connect app iframe. However, after creating the user property I logged out from Confluence and logged in with a different user and this user was able to read, modify and delete the property.

So as mentioned in my previous comment I don’t see a real value for this new API as its current functionality can already be “simulated” with the app property API (just to avoid misunderstanding: I’m referring to App properties API). The app property API even supports the app isolation which means when I try to access an app property of app X from a Connect iframe of app Y, the API returns a 404.

For storing data in a user property I would currently see the following 2 use cases which can’t be implemented with the new API:

  1. Storing some data in my properties which other Confluence users are allowed to see but only I can modify or delete. For example some profile information you would like to share with others. But you would definitely expect that no one else is able to change it.
  2. Storing private data in my properties which can only be accessed by me. This could for instance be used for preferences for certain features of an app as mentioned by Candid or generating personalized results. Such information could be sensitive and shouldn’t be accessible by others.

Of course, other devs might have different needs.

1 Like

Yes, thanks for the feedback.
I understand a different user was signed in the second time but it was still the same connect app calling this API from within a connect iframe using AP.request.

Even with these new APIs, if you use connect iframe of app Y, properties won’t be modifiable/accessible.

#1 wasn’t in scope for these new APIs as we have other functionality to provide read only profile information.
#2 this is the goal for sure and exactly what we’re offering. The way we look at it is app X created properties when signed in user was A, now even if the signed in user is B app X should still be able to modify those properties created for user A as it is still the same app. However, app Y in neither of the cases (signed in user being A or B) can alter these properties.

If you think having additional checks to make sure properties created by app X for user A when A was signed in shouldn’t be accessible by app X for user A when B was signed in, we can consider adding restrictions.

Thanks

1 Like

wasn’t in scope for these new APIs as we have other functionality to provide read only profile information.

Is this functionality also available for app developers? If so, how can we use it?

this is the goal for sure and exactly what we’re offering

Maybe a misunderstanding. Having the app isolation is a good thing, but in my 2nd scenario this isn’t enough. In addition it should also be ensured that the user who created the user property should be the only one who can read, modify or delete it. If just any user could take the browser dev tools and tamper with properties of other users, I can’t really use them for things like preferences.

we can consider adding restrictions

This sounds good!

@JatinChopra can we use these as Connect Conditions?

Was anyone successful in implementing this? When I try to follow the description I get a 400 back without any further details…

HI, can you share more details for the issue you are facing? I can see other vendors able to perform create, read, modify, delete operations using the APIs pointed out in the post.

Thanks

Use case is upto the vendors as long as the app makes a call to READ these properties. Please feel free to try and let us know if you face any issues.
For now we don’t plan on having these added to existing Connect conditions. We might consider adding new Forge capabilities depending on vendor ask.

Thanks

Dear @JatinChopra ,

thanks for the quick answer. It was my fault. I overlooked that the value itself must be JSON object.

Best regards

Andreas

1 Like

We added forge/OAuth scopes now to these APIs too. Please feel free to try them and let us know if you run into any issues.

Thanks

1 Like
  1. Please feel free to use User APIs for that.
  2. We’ll add this restriction shortly: If the app makes a call asUser , then it won’t be allow to read, alter or delete properties for a different user. However, if it makes calls asApp , it can do all these operations.

Please let us know if this satisfies all your requirements. We’d love to see this feature help our vendors succeed and create amazing customized experiences for our users.

Thanks

2 Likes

@JatinChopra that’s disappointing to hear it would only be considered on Forge. If I could use in Connect now, I have use cases such as avoiding loading web panels unnecessarily because I need to check the status of something relative to the user.

2 Likes

@JatinChopra thank you for the update.
Using the user API you linked wouldn’t solve my first scenario as it doesn’t allow adding custom information to the profile.
However, I actually have more need for the 2nd scenario. The restriction you described looks really nice and would fulfill my requirements.