We noticed that there is an issue with the security of pages in the blog feed. When the correct page restriction is set prior to saving a blog post, there is no issue. However, in can you save the blog post without setting the page restrictions, and you set these restrictions afterwards, the blog post is still visible on the blog feed.

      In case a user that has no access to this particular blog post clicks on it, he gets a message stating "You do not have permission to view this page. Request access below, you will receive an email when you've been granted access.".

      If you go to the blog instead of the blog feed the page restrictions are applied correctly, restricted pages are hidden from the tree in case the logged in user doesn't have the correct access rights (no issue here).

            [CONFSERVER-40908] Inconsistency in page security in blog feed

            Don Willis added a comment - - edited

            Versions with this bug

            Version Tested works as expected
            6.0.2
            6.1.3
            6.2.0
            6.2.4
            6.3.4

            And suddenly it becomes easier to find what it's a duplicate of.  

            It's a straight duplicate of CONFSERVER-51816 which was fixed in 6.1.4.

            Don Willis added a comment - - edited Versions with this bug Version Tested works as expected 6.0.2 6.1.3 6.2.0 6.2.4 6.3.4 And suddenly it becomes easier to find what it's a duplicate of.   It's a straight duplicate of CONFSERVER-51816 which was fixed in 6.1.4.

            Don Willis added a comment - - edited

            I cannot reproduce this on 6.14. It seems to have been fixed, possibly in 6.7.0 by the fix to CONFSERVER-40833. I'll try to verify that's the case and if so update the status of the issue.

            Don Willis added a comment - - edited I cannot reproduce this on 6.14. It seems to have been fixed, possibly in 6.7.0 by the fix to CONFSERVER-40833 . I'll try to verify that's the case and if so update the status of the issue.

            When can we expect here a solution ? It can not be that so important tickets are so long in the status "Open". For our users this functionality is really relevant.

            Thank you,

            Karina

            Karina Vogelsang added a comment - When can we expect here a solution ? It can not be that so important tickets are so long in the status "Open". For our users this functionality is really relevant. Thank you, Karina

            The priority was set as low. Maybe the reporter can up it.

            Kristin Bitler (mty.k12) added a comment - The priority was set as low. Maybe the reporter can up it.

            This is a security issue.. how is this not picked up?

            Patrick van der Rijst added a comment - This is a security issue.. how is this not picked up?

            We have the same problem. Pls fix.

            Yanick Belart added a comment - We have the same problem. Pls fix.

            I can confirm this CRITICAL bug for Confluence 6.0.2

            I suggest fixing it together with the bug that Confluence admins / System admins are not able to see restricted blog posts that are restricted to them. There's no way an admin ever gets a chance to edit/delete/move/unrestrict this page. Our auditors are running mad...

            Jan-Peter Rusch added a comment - I can confirm this CRITICAL bug for Confluence 6.0.2 I suggest fixing it together with the bug that Confluence admins / System admins are not able to see restricted blog posts that are restricted to them. There's no way an admin ever gets a chance to edit/delete/move/unrestrict this page. Our auditors are running mad...

            Remo Siegwart added a comment - - edited

            The priority of this bug should really be increased! We are seeing restricted blog posts not only in the blog post macro, but also in site search, quick search, REST API, Java API, etc. Depending on the content of the blog post, this can be a major issue for users/customers!

            Problem description

            Restricted blog posts are still being displayed in the blog posts macro, site search, quick search, REST API, Java API, etc. when the restrictions have been added AFTER the blog post has been published.

            Steps to reproduce

            1. Create a new blog post and publish it without having any restrictions.
            2. After the blog post has been published, restrict viewing of this post to User A
            3. Now login as User B => the restricted blog post will still show up in the blog post macro, search, REST API, etc.

            Workaround

            Always make sure to add all restrictions on blog posts BEFORE you publish them. After you have published the post, it's too late to add any new restrictions...

            Remo Siegwart added a comment - - edited The priority of this bug should really be increased! We are seeing restricted blog posts not only in the blog post macro, but also in site search, quick search, REST API, Java API, etc. Depending on the content of the blog post, this can be a major issue for users/customers! Problem description Restricted blog posts are still being displayed in the blog posts macro, site search, quick search, REST API, Java API, etc. when the restrictions have been added AFTER  the blog post has been published. Steps to reproduce Create a new blog post and publish it without having any restrictions. After the blog post has been published, restrict viewing of this post to User A Now login as User B => the restricted blog post will still show up in the blog post macro, search, REST API, etc. Workaround Always make sure to add all restrictions on blog posts BEFORE  you publish them. After you have published the post, it's too late to add any new restrictions...

              Unassigned Unassigned
              95eca6e4f6cd wim baert
              Affected customers:
              16 This affects my team
              Watchers:
              14 Start watching this issue

                Created:
                Updated:
                Resolved: