We are experiencing some issues with restriction handling on custom content.
Scenario 1: Container page is view-restricted, custom content is not
Accessing it through /rest/api/content/<id> gives me a com.atlassian.confluence.api.service.exceptions.PermissionException: Parent page view is restricted (correct behaviour).
The custom content is not listed in /rest/api/content/?spaceKey=<spaceKey>&type=<custom content type> (correct behaviour)
I can find the custom content through /rest/api/search. We have observed a similar behaviour on Server, and there it can be solved by rebuilding the search index. I don’t think there is a way to do that on Cloud though?
The behaviour changes when I add any expansion to the /rest/api/search call. If the custom content is the only (or maybe the first?) result of the request, it fails with a 500 java.lang.IllegalArgumentException: start cannot be less than zero. This causes a crash in our app at the moment. If there are multiple results, the request succeeds, but the custom content is not part of the results anymore.
Scenario 2: Container page and custom content are both view-restricted
The custom content cannot be accessed in any of the 3 ways (correct behaviour)
Scenario 3: Custom content is view-restricted, container page is not
The custom content cannot be accessed in any of the 3 ways (correct behaviour). This seems to contradict these findings.
Scenario 4: Neither the page nor the custom content are restricted
Now the space permissions should apply (page permissions for the page and attachment permissions for the custom content). The custom content can be accessed properly, but now it seems that all users have permission to update the custom content, even anonymous users, as long as they have read permission in the space!
My name is Engin, I’m an engineer at Confluence Cloud Ecosystem team. Thank you for investigating and creating this topic. I’ve tried the scenarios you mentioned, here are my findings:
As a workaround for scenario 1.3, we have found that saving a new revision of the custom content both fixes the exception and correctly hides the item from the search results.
I have found another interesting detail about this bug 1.3. It turns out that when creating a custom content object under a view-restricted page, and then unrestricting that page, the custom content can still not be found through CQL by users who previously didn’t have access to it. Saving a new version of the custom content fixes the problem.
This confirms my suspicion that the problem is that when changing the restrictions of a page, the restrictions of the custom content underneath it are not updated in the search index.
@toshihiro As far as I understand, custom content should be accessible to anonymous users as long as they have “View attachments” permission in the space and there are no content restrictions on the content.