• 42
    • 24
    • Our product teams collect and evaluate feedback from a number of different sources. To learn more about how we use customer feedback in the planning process, check out our new feature policy.

      NOTE: This suggestion is for Confluence Cloud. Using Confluence Server? See the corresponding suggestion.

      I understand that I can globally change anonymous access, but here at a university, we de-centralize the space administration to the professors. We have a policy of no anonymous write permission is allowed to spaces. However, profs do it anyway, and the spaces get spammed very quickly and very heavily. I understand that I can turn on CAPTCHA, but I'd prefer to be able to simply turn off the ability for anyone anonymous to edit a space and keep it that way, from the server administrator's screen.

      Thank you.

        1. global_perms.jpg
          255 kB
          James Cramton
        2. space_perms.jpg
          254 kB
          James Cramton

          Form Name

            [CONFCLOUD-8844] Prevent space admins from changing anonymous access

            Champion added a comment -

            Adding a vote! 

            I'm interested in allowing anonymous access to specific KB spaces/pages but allowing all space admins the ability to accidentally enable this feature is enough of  a security risk to the point where allowing anonymous access at all is not possible with the current access settings.

            Champion added a comment - Adding a vote!  I'm interested in allowing anonymous access to specific KB spaces/pages but allowing all space admins the ability to accidentally enable this feature is enough of  a security risk to the point where allowing anonymous access at all is not possible with the current access settings.

            Confluence Cloud Permissions PM here. Thanks for this feedback, and we are looking into ways to keep the Global anonymous access controls in sync/forcibly aligned with the Space anonymous access controls. Any feedback is appreciated. 

            Kristen Waters added a comment - Confluence Cloud Permissions PM here. Thanks for this feedback, and we are looking into ways to keep the Global anonymous access controls in sync/forcibly aligned with the Space anonymous access controls. Any feedback is appreciated. 

            FWIW - we started getting some spam on our wiki and discovered it was from users enabling anonymous comments within personal spaces. I created a simple Python script to scan permissions within all personal spaces and remove any permissions other than "read" granted to anonymous users. In our case, this script scanned over 100 personal spaces, found three spaces with bogus permissions (all were permissions to create comments), and removed them. You have to edit it for your domain and manually supply username & API token (or send via environment), but it's (slightly) better than nothing for now.

            Burke Mamlin added a comment - FWIW - we started getting some spam on our wiki and discovered it was from users enabling anonymous comments within personal spaces. I created a simple Python script to scan permissions within all personal spaces and remove any permissions other than "read" granted to anonymous users. In our case, this script scanned over 100 personal spaces, found three spaces with bogus permissions (all were permissions to create comments), and removed them. You have to edit it for your domain and manually supply username & API token (or send via environment), but it's (slightly) better than nothing for now.

            Our organisation also needs the ability to globally disable Anonymous Access configuration on individual Spaces (or enforce a tenant-wide Anonymous Access configuration). Our Space Admin is also delegated to area leads. Some of our users in our tenant are only granted access to Specific Spaces based on their Group, and we have to be very careful what they can see due to sensitivity of data and/or contracts with third parties. If a Space Admin accidentally enables Anonymous Access, then every single licensed user in Confluence can see it and it undermines any restriction on data sharing.

            Why oh why you would grant the option to disable Anonymous Access globally and have it just so that external/anonymous users can't see it, without also actually disabling it globally so that internal users can't use it. There is no use for this feature when it is disabled to external users; how has it been allowed to create an unnecessary by-product effect of making the Space visibile to everyone?! This could be easily achieved by adding jira-software-users to the Groups section of Space permissions...

            (Yes we are aware of Page Restrictions, but end-users who manage the data are not. These are fiddly in themselves when adding specific users who might leave/join - end-users can't manage their own Groups for their teams, so doing so would create more overhead on the Admins.)

            Sam Forrester added a comment - Our organisation also needs the ability to globally disable Anonymous Access configuration on individual Spaces (or enforce a tenant-wide Anonymous Access configuration). Our Space Admin is also delegated to area leads. Some of our users in our tenant are only granted access to Specific Spaces based on their Group, and we have to be very careful what they can see due to sensitivity of data and/or contracts with third parties. If a Space Admin accidentally enables Anonymous Access, then every single licensed user in Confluence can see it and it undermines any restriction on data sharing. Why oh why you would grant the option to disable Anonymous Access globally and have it just so that external/anonymous users can't see it, without also  actually disabling it globally so that internal users can't use it. There is no use for this feature when it is disabled to external users; how has it been allowed to create an unnecessary by-product effect of making the Space visibile to everyone?! This could be easily achieved by adding jira-software-users to the Groups section of Space permissions... (Yes we are aware of Page Restrictions, but end-users who manage the data are not. These are fiddly in themselves when adding specific users who might leave/join - end-users can't manage their own Groups for their teams, so doing so would create more overhead on the Admins.)

            Wenbo Sun added a comment -

            We recently looked into the guest access feature in beta and found the anonymous access setting on space level can be a big security risk to us. We have anonymous global setting disabled. But if space owner enables anonymous access for some reason, an invited guest account will get access to the space. This can be resolved by give an option to remove such setting from space admin.

            Wenbo Sun added a comment - We recently looked into the guest access feature in beta and found the anonymous access setting on space level can be a big security risk to us. We have anonymous global setting disabled. But if space owner enables anonymous access for some reason, an invited guest account will get access to the space. This can be resolved by give an option to remove such setting from space admin.

            We had the same problem here at the University of Helsinki and have now a daily script checking and removing unnecessary permissions for anonymous users (other than 'view' and 'comments -add'). If you are interested in it I can ask further details from our sys admin.

            However, there should be more options on the global admin's panel.

            Antero Aunesluoma added a comment - We had the same problem here at the University of Helsinki and have now a daily script checking and removing unnecessary permissions for anonymous users (other than 'view' and 'comments -add'). If you are interested in it I can ask further details from our sys admin. However, there should be more options on the global admin's panel.

            I need as the central Admin the ability to exclude the "Anonymous Access" options for Space Admins to enable from certain spaces.
            It would be a catastrophy if a Space Admin by accident opened certain content to the public for viewing - even worse for editing.

            Ole Kristensen added a comment - I need as the central Admin the ability to exclude the "Anonymous Access" options for Space Admins to enable from certain spaces. It would be a catastrophy if a Space Admin by accident opened certain content to the public for viewing - even worse for editing.

            Igor Minar added a comment -

            This is exactly what we need as well.

            Writing a script that checks permission and creates an alert if rules are violated sounds like an afterthought solution. Security should never be an afterthought.

            The three main problems with script workaround are:

            • constant maintenance of the wikis is needed - when an alert is issued a site admin has to log in and fix the issue (this could be automated within the script though I guess)
            • there is a window of opportunity for anonymous users to post things from the moment the write access has been granted, until the violation is found and fixed.
            • bad user experience - "I turned this on, it was on for 5 hours, and now it's off! This system is weird!"

            Igor Minar added a comment - This is exactly what we need as well. Writing a script that checks permission and creates an alert if rules are violated sounds like an afterthought solution. Security should never be an afterthought. The three main problems with script workaround are: constant maintenance of the wikis is needed - when an alert is issued a site admin has to log in and fix the issue (this could be automated within the script though I guess) there is a window of opportunity for anonymous users to post things from the moment the write access has been granted, until the violation is found and fixed. bad user experience - "I turned this on, it was on for 5 hours, and now it's off! This system is weird!"

            Could we also perhaps have a script that just returns "1" if there are any spaces with anonymous access? Or a perl script that returns a list of spaces with anon access?

            That way you could just have a cron job that runs nightly (hourly?) and will email you (and/or the admin of that space) notifying them that this is a problem?

            I think that this would be relatively easy to do?

            Scott Farquhar added a comment - Could we also perhaps have a script that just returns "1" if there are any spaces with anonymous access? Or a perl script that returns a list of spaces with anon access? That way you could just have a cron job that runs nightly (hourly?) and will email you (and/or the admin of that space) notifying them that this is a problem? I think that this would be relatively easy to do?

            Attached screenshots of global and space permissions to help explain Brown's requirements:

            • Globally prevent space admins and page owners from changing space or page permissions that permit anonymous editing or commenting.
            • Some spaces may be world-readable; some may be restricted to the Brown community.
            • No spaces should be writable by anonymous--applies to pages, news, comments, attachments, mail, and space permissions.
            • We can currently configure these settings, but space admins behaving badly can modify the space settings to allow anonymous comments or editing. We need to prevent this capability.
            • Recommendation:
              Current global perms on anonymous use only permit administrators to set "Can Use." If this were split into "Can Read" and Can Write," the space perms page could better distinguish view vs. other permissions.
              If administrators globally set perms so that anonymous can only read, then the space perms page would only permit space admins to modify the View setting (off or on), and the rest of the anonymous settings (pages, news, comments, attachments, mail, and space) would not be modifiable by the space admin. If both Can Read and Can Write were set for anonymous at the global level, then the space admins could decide how to administer perms, just as they do today under the current "Can Use" setting. You may need to allow Confluence Administrators to modify the settings regardless, but space admins would be restricted.

            James Cramton added a comment - Attached screenshots of global and space permissions to help explain Brown's requirements: Globally prevent space admins and page owners from changing space or page permissions that permit anonymous editing or commenting. Some spaces may be world-readable; some may be restricted to the Brown community. No spaces should be writable by anonymous--applies to pages, news, comments, attachments, mail, and space permissions. We can currently configure these settings, but space admins behaving badly can modify the space settings to allow anonymous comments or editing. We need to prevent this capability. Recommendation: Current global perms on anonymous use only permit administrators to set "Can Use." If this were split into "Can Read" and Can Write," the space perms page could better distinguish view vs. other permissions. If administrators globally set perms so that anonymous can only read, then the space perms page would only permit space admins to modify the View setting (off or on), and the rest of the anonymous settings (pages, news, comments, attachments, mail, and space) would not be modifiable by the space admin. If both Can Read and Can Write were set for anonymous at the global level, then the space admins could decide how to administer perms, just as they do today under the current "Can Use" setting. You may need to allow Confluence Administrators to modify the settings regardless, but space admins would be restricted.

              ee1911a8f30a Marie Casabonne
              ddb1171e8acf Patrick Laverty
              Votes:
              45 Vote for this issue
              Watchers:
              45 Start watching this issue

                Created:
                Updated: