Uploaded image for project: 'Confluence Data Center'
  1. Confluence Data Center
  2. CONFSERVER-30161

Allow unlicensed, authenticated users to have anonymous read only access

XMLWordPrintable

    • 12
    • 108
    • We collect Confluence feedback from various sources, and we evaluate what we've collected when planning our product roadmap. To understand how this piece of feedback will be reviewed, see our Implementation of New Features Policy.
    • Hide
      Atlassian Update - 27 Feb 2024

      Hi everyone,
      This is Richa Srivastava from the Confluence team. Thank you for your interest in this suggestion.
      While we appreciate the significant interest in this ticket, unfortunately we can’t implement every great idea. We continue to review the most urgent needs of our customers, and at this time have to prioritise other areas of Confluence, which include some highly voted suggestions.
      You can read more about how we prioritise what to implement here\.
      To learn more about our recent investments in Confluence Data Center, please check our public roadmap\ and our dashboards containing recently resolved issues\, and current work and future plans\.
      Kind regards,
      Confluence Data Center
      Show
      Atlassian Update - 27 Feb 2024 Hi everyone, This is Richa Srivastava from the Confluence team. Thank you for your interest in this suggestion. While we appreciate the significant interest in this ticket, unfortunately we can’t implement every great idea. We continue to review the most urgent needs of our customers, and at this time have to prioritise other areas of Confluence, which include some highly voted suggestions. You can read more about how we prioritise what to implement here\. To learn more about our recent investments in Confluence Data Center, please check our public roadmap\ and our dashboards containing recently resolved issues\, and current work and future plans\. Kind regards, Confluence Data Center

      Atlassian Update – 17 May 2024

      Hi everyone,

      Thank you for your interest in this suggestion. We’ve reviewed this since the last update, and understand that the current behaviour for unlicensed, authenticated users is unintuitive. While it may appear simple on the surface, making changes to permissions always tends to be a complex undertaking. At this time, we do not have an update as to when we’ll work on this, though we will keep it open for future consideration, and will share any updates here.

      To learn more about our recent investments in Confluence Data Center, please check our public roadmap and our dashboards containing recently resolved issues, and current work.

      Kind regards,

      Jacqueline Bietz
      Product Manager
      Confluence Data Center

      Problem Definition

      If a user (e.g. a JIRA user) is not licensed to use Confluence, they cannot view any Confluence content (from JIRA or Service Desk for instance) - even if that content is available to anonymous users. They currently have to log out before they can see the content. Customers have also asked for anonymous, read-only access for authenticated users that are not coming from a JIRA User Directory.

      Suggested Solution for non-Service Desk customers

      We cannot allow authenticated but unlicensed users to edit anonymously accessible content, since that would mean that admins would only have to enable anonymous access to have the equivalent of an unlimited user license.
      Instead, we should allow authenticated but unlicensed users to get read-only access to confluence content with anonymous permissions.

      Such users will still be locked out from parts of the application that require a licensed user, including viewing user profiles, people directories, etc, unless anonymous has been granted permission to view user profiles.

      Solution for JIRA Service Desk customers

      Link JIRA Service Desk project to Confluence space to allow customers to have access to knowledge base in Project Settings -> Knowledge Base.

        1. Screen Shot 2016-09-30 at 3.08.07 PM.png
          Screen Shot 2016-09-30 at 3.08.07 PM.png
          122 kB
        2. Screen Shot 2016-09-30 at 4.36.55 PM.png
          Screen Shot 2016-09-30 at 4.36.55 PM.png
          43 kB

            [CONFSERVER-30161] Allow unlicensed, authenticated users to have anonymous read only access

            Ray Stone added a comment - - edited

            This issue was created almost twelve years ago, I first found it about 6-7 years ago. I have been following it ever since.  Based on some previous comments, this has cost Atlassian revenue. It was a show stopper for some customers and they moved on to other products. I even received some PM's about it.

            Interestingly, I am about to retire and will never see this addressed. We where one of the customers who moved on to other products. 

            Ray Stone added a comment - - edited This issue was created almost twelve years ago, I first found it about 6-7 years ago. I have been following it ever since.  Based on some previous comments, this has cost Atlassian revenue. It was a show stopper for some customers and they moved on to other products. I even received some PM's about it. Interestingly, I am about to retire and will never see this addressed. We where one of the customers who moved on to other products. 

            Andy Hurley added a comment -

            This is causing a MAJOR problem for us. We have JSM and Confluence with thousands of end users but only a few dozen service desk agents and admins who have a licence on JSM and Confluence.

            The portal users are able to submit tickets and view knowledge articles and we have been trialling Forms for Confluence to allow them to submit questionnaires as well but this change means that we are unable to do that. The users are authenticated via SSO (no option to log out and be anonymous) and are able to view the questionnaires but are not able to submit them because of this change.

            The irony is that, if they were able to be fully anonymous, they would be able to submit the forms without any problem so this change is allowing anonymous users to do more than authenticated (but unlicensed) ones.

            I fear that this is a case of unintended consequences and is unlikely to ever be fixed.

            Andy Hurley added a comment - This is causing a MAJOR problem for us. We have JSM and Confluence with thousands of end users but only a few dozen service desk agents and admins who have a licence on JSM and Confluence. The portal users are able to submit tickets and view knowledge articles and we have been trialling Forms for Confluence to allow them to submit questionnaires as well but this change means that we are unable to do that. The users are authenticated via SSO (no option to log out and be anonymous) and are able to view the questionnaires but are not able to submit them because of this change. The irony is that, if they were able to be fully anonymous, they would be able to submit the forms without any problem so this change is allowing anonymous users to do more than authenticated (but unlicensed) ones. I fear that this is a case of unintended consequences and is unlikely to ever be fixed.

            Dalton Rick added a comment -

            We continue to review the most urgent needs of our customers, and at this time have to prioritise other areas of Confluence, which include some highly voted suggestions

             
            Would the list below be the "highly voted suggestions" that were prioritized over this long standing bug that Atlassian wants to pretend is a feature request?

            The answer is obvious when you look at the board, you are just picking up simple easy tickets, the majority of which not a single soul has voted for, to make it look like your doing lots of work on your datacenter products, while what you are actually doing is lying to your datacenter customers while spending all your real resources pushing your more expense, less secure cloud offering.

            I mean hell, you can't even honestly call this what it is, its a bug, its not a feature request. "please make the product work the way the documentation says it should work" is never a feature request in any product. Documentation, comments from Atlassian agents on related tickets and helper text above the actual anonymous row in space permissions all say that logged in users will have access, and thats not accurate. So, the product does not work the way the product documentation says it will work. Calling this a feature request and telling your users that you are too busy to work on it because your spending all your time working on other suggestions with 372 less votes than this ticket with 372 votes is a slap in the face to your customers.

            Dalton Rick added a comment - We continue to review the most urgent needs of our customers, and at this time have to prioritise other areas of Confluence, which include some highly voted suggestions   Would the list below be the "highly voted suggestions" that were prioritized over this long standing bug that Atlassian wants to pretend is a feature request? https://jira.atlassian.com/browse/CONFSERVER-94282 https://jira.atlassian.com/browse/CONFSERVER-95558 https://jira.atlassian.com/browse/CONFSERVER-95567 https://jira.atlassian.com/browse/CONFSERVER-94863 https://jira.atlassian.com/browse/CONFSERVER-91500 https://jira.atlassian.com/browse/CONFSERVER-90915 https://jira.atlassian.com/browse/CONFSERVER-87291 https://jira.atlassian.com/browse/CONFSERVER-87290 https://jira.atlassian.com/browse/CONFSERVER-94274 https://jira.atlassian.com/browse/CONFSERVER-83907 https://jira.atlassian.com/browse/CONFSERVER-91514 https://jira.atlassian.com/browse/CONFSERVER-90387 https://jira.atlassian.com/browse/CONFSERVER-90385 https://jira.atlassian.com/browse/CONFSERVER-87292 https://jira.atlassian.com/browse/CONFSERVER-58676 https://jira.atlassian.com/browse/CONFSERVER-82851 https://jira.atlassian.com/browse/CONFSERVER-92826 https://jira.atlassian.com/browse/CONFSERVER-75953 https://jira.atlassian.com/browse/CONFSERVER-55528 https://jira.atlassian.com/browse/CONFSERVER-54913 https://jira.atlassian.com/browse/CONFSERVER-73725 https://jira.atlassian.com/browse/CONFSERVER-79908 https://jira.atlassian.com/browse/CONFSERVER-55610 https://jira.atlassian.com/browse/CONFSERVER-82530 https://jira.atlassian.com/browse/CONFSERVER-94161 https://jira.atlassian.com/browse/CONFSERVER-81426 https://jira.atlassian.com/browse/CONFSERVER-12689 https://jira.atlassian.com/browse/CONFSERVER-33081 https://jira.atlassian.com/browse/CONFSERVER-81596 https://jira.atlassian.com/browse/CONFSERVER-57907 https://jira.atlassian.com/browse/CONFSERVER-60949 https://jira.atlassian.com/browse/CONFSERVER-60668 https://jira.atlassian.com/browse/CONFSERVER-33899 https://jira.atlassian.com/browse/CONFSERVER-7905 https://jira.atlassian.com/browse/CONFSERVER-57879 https://jira.atlassian.com/browse/CONFSERVER-83208 https://jira.atlassian.com/browse/CONFSERVER-94488 https://jira.atlassian.com/browse/CONFSERVER-43625 https://jira.atlassian.com/browse/CONFSERVER-40015 https://jira.atlassian.com/browse/CONFSERVER-7260 https://jira.atlassian.com/browse/CONFSERVER-3698 https://jira.atlassian.com/browse/CONFSERVER-7002 https://jira.atlassian.com/browse/CONFSERVER-43063 The answer is obvious when you look at the board , you are just picking up simple easy tickets, the majority of which not a single soul has voted for, to make it look like your doing lots of work on your datacenter products, while what you are actually doing is lying to your datacenter customers while spending all your real resources pushing your more expense, less secure cloud offering. I mean hell, you can't even honestly call this what it is, its a bug, its not a feature request. "please make the product work the way the documentation says it should work" is never a feature request in any product. Documentation, comments from Atlassian agents on related tickets and helper text above the actual anonymous row in space permissions all say that logged in users will have access, and thats not accurate. So, the product does not work the way the product documentation says it will work. Calling this a feature request and telling your users that you are too busy to work on it because your spending all your time working on other suggestions with 372 less votes than this ticket with 372 votes is a slap in the face to your customers.

            mbeda@summitracing.com added a comment -

            This could be solved easily by just giving us another license tier for read-only authenticated access. The issue is we have thousands of users that never need to edit any content ever! and the business cannot justify purchasing full licenses for read-only users. We would rather have authenticated read-only users so we can at-least restrict access to content based on group but still not give users access to edit while still not turning on anonymous access (since this is a security risk). If commenting is the issue with Edit rights and the reason why all users must have a full license, then just turn off comments for this license tier. It is not justifiable to just ignore this thread. We as users would rather pay for read-only access then have to do the work-arounds we most likely will have to do to bypass this issue.

            mbeda@summitracing.com added a comment - This could be solved easily by just giving us another license tier for read-only authenticated access. The issue is we have thousands of users that never need to edit any content ever! and the business cannot justify purchasing full licenses for read-only users. We would rather have authenticated read-only users so we can at-least restrict access to content based on group but still not give users access to edit while still not turning on anonymous access (since this is a security risk). If commenting is the issue with Edit rights and the reason why all users must have a full license, then just turn off comments for this license tier. It is not justifiable to just ignore this thread. We as users would rather pay for read-only access then have to do the work-arounds we most likely will have to do to bypass this issue.

            David Redwine added a comment -

            As was mentioned back on 12/Jan/2021.......this is so far beyond stupid it just defies belief that the product manager hasn't been fired over this issue. So our portal users who are our customers cannot view any KB article content or lists or instructions we want to provide them as they are creating a ticket? This just boggles the brain.

            Even though portal users are unlicensed, they have to logout of atlassian just to see anonymous content? On top of that, atlassian keeps intercepting the portal users attempt to view anonymous confluence content, so that the users are forced to use an incognito browser window just to access anonymous confluence content! Unbelievable!!!

            David Redwine added a comment - As was mentioned back on 12/Jan/2021.......this is so far beyond stupid it just defies belief that the product manager hasn't been fired over this issue. So our portal users who are our customers cannot view any KB article content or lists or instructions we want to provide them as they are creating a ticket? This just boggles the brain. Even though portal users are unlicensed, they have to logout of atlassian just to see anonymous content? On top of that, atlassian keeps intercepting the portal users attempt to view anonymous confluence content, so that the users are forced to use an incognito browser window just to access anonymous confluence content! Unbelievable!!!

            Andrew Laden added a comment -

            This is not a suggestion. It is a bug, and a 10+ year old one at at that. It is absolutely flabbergasting that you still wont address what is clearly broken behavior that requires users to log out of your own product in order to be able to view pages and features that by definition anyone should be able to access. 

             

            Andrew Laden added a comment - This is not a suggestion. It is a bug, and a 10+ year old one at at that. It is absolutely flabbergasting that you still wont address what is clearly broken behavior that requires users to log out of your own product in order to be able to view pages and features that by definition anyone should be able to access.   

            Richa Srivastava (Inactive) added a comment - - edited
            Atlassian Update - 27 Feb 2024

            Hi everyone,
            This is Richa Srivastava from the Confluence team. Thank you for your interest in this suggestion.
            While we appreciate the significant interest in this ticket, unfortunately we can’t implement every great idea. We continue to review the most urgent needs of our customers, and at this time have to prioritise other areas of Confluence, which include some highly voted suggestions.
            You can read more about how we prioritise what to implement here\.
            To learn more about our recent investments in Confluence Data Center, please check our public roadmap\ and our dashboards containing recently resolved issues\, and current work and future plans\.
            Kind regards,
            Confluence Data Center

            		  

            Richa Srivastava (Inactive) added a comment - - edited Atlassian Update - 27 Feb 2024 Hi everyone, This is Richa Srivastava from the Confluence team. Thank you for your interest in this suggestion. While we appreciate the significant interest in this ticket, unfortunately we can’t implement every great idea. We continue to review the most urgent needs of our customers, and at this time have to prioritise other areas of Confluence, which include some highly voted suggestions. You can read more about how we prioritise what to implement here\ . To learn more about our recent investments in Confluence Data Center, please check our public roadmap\ and our dashboards containing recently resolved issues\ , and current work and future plans\ . Kind regards, Confluence Data Center  

            Dalton Rick added a comment -

            Bumping as this affects our customers ability to access our KB space. 

             

            I cannot think of a business use case that would benefit from blocking known, unlicensed users from viewing a public page but allow unknown, unlicensed users to view the page. All a known user has to do to "violate" the access control restrictions is log out. Since anonymous users are by their nature, unlicensed, this behavior as it stands today 1. Does not provide any sort of practical security to the page(s) in question, 2. Is not preventing any kind of abuse of the licensing system. 

             

            Additionally, the behavior as it stands today does not match what the documentation and comments by Atlassian engineers in another ticket says it does:

             

            In Confluence 7.19.5, if you go to a Space's Permissions page and look under the Anonymous user section, it says: 
            > Grant permissions to anonymous users (people who are not logged in). We recommend limiting this to viewing and commenting. People who are logged in will also get these permissions, even if your administrator has turned off anonymous access for this site

             

            Of special note: 
            > People who are logged in will also get these permissions

            And for even more clarity, @Mahesh Swami's comment on CONFSERVER-66177 on July 13, 2021 says: 
            > The description would clearly mention that the "anonymous" permissions apply to "all the logged in users".

            Dalton Rick added a comment - Bumping as this affects our customers ability to access our KB space.    I cannot think of a business use case that would benefit from blocking known, unlicensed users from viewing a public page but allow unknown, unlicensed users to view the page. All a known user has to do to "violate" the access control restrictions is log out. Since anonymous users are by their nature, unlicensed, this behavior as it stands today 1. Does not provide any sort of practical security to the page(s) in question, 2. Is not preventing any kind of abuse of the licensing system.    Additionally, the behavior as it stands today does not match what the documentation and comments by Atlassian engineers in another ticket says it does:   In Confluence 7.19.5, if you go to a Space's Permissions page and look under the Anonymous user section, it says:  > Grant permissions to anonymous users (people who are not logged in). We recommend limiting this to viewing and commenting. People who are logged in will also get these permissions, even if your administrator has turned off anonymous access for this site   Of special note:  > People who are logged in will also get these permissions And for even more clarity, @Mahesh Swami's comment on CONFSERVER-66177 on July 13, 2021 says:  > The description would clearly mention that the "anonymous" permissions apply to "all the logged in users".

            Kieren Smith added a comment -

            Bumping this issue due to response from AppFire, when querying why I as an authenticated, logged in Cloud user, am not permitted to access the supposedly accessible-to-all documentation for our purchased apps:

            This is a known issue by Atlassian and its not specific to our app.

            please refer [2]https://jira.atlassian.com/browse/CONFSERVER-30161

            Currently the only work around available is to open the url when without being logged in or in incognito mode.

            This issue affects our ability as a paying customer to access documentation for our paid apps, even if we are on Cloud - as the issue is local to the Confluence instance, not the user trying to access the page(s).

             

            Kieren Smith added a comment - Bumping this issue due to response from AppFire, when querying why I as an authenticated, logged in Cloud user, am not permitted to access the supposedly accessible-to-all documentation for our purchased apps: This is a known issue by Atlassian and its not specific to our app. please refer [2] https://jira.atlassian.com/browse/CONFSERVER-30161 Currently the only work around available is to open the url when without being logged in or in incognito mode. This issue affects our ability as a paying customer to access documentation for our paid apps, even if we are on Cloud - as the issue is local to the Confluence instance, not the user trying to access the page(s).  

            Daniel Varela Santoalla added a comment - - edited

            Bumped into this (sadly, very very old) problem right now, as we are migrating from an unlimited Open Source Server licence to a more restricted Data Center one. One could imagine that moving on from paying zero dollars to a five figure number all that we would get is "improvements", so it is very upsetting to be hit by this problem.

            We do have many "registered" users that will not be licensed under the new Data Center installation, and we do have quite a lot of public content accessible to anonymous users. We cannot delete those users as they are used with the SSO and might be licensed in other systems, and on top of that they might have "authored" content in the past, for sure in Jira Service Management.

            It is such a simple thing to fix and yet so incredibly frustrating that it hasn't yet Why? Could please Atlassian justify the inaction, as it cannot be about availability of development resources. Something that I believe would work would be just a setting (that could be enabled via a system property if necessary) to auto-logout unlicensed users, so that they are reverted automatically to "anonymous". I cannot see any big issue with this approach.

            Daniel Varela Santoalla added a comment - - edited Bumped into this (sadly, very very old) problem right now, as we are migrating from an unlimited Open Source Server licence to a more restricted Data Center one. One could imagine that moving on from paying zero dollars to a five figure number all that we would get is "improvements", so it is very upsetting to be hit by this problem. We do have many "registered" users that will not be licensed under the new Data Center installation, and we do have quite a lot of public content accessible to anonymous users. We cannot delete those users as they are used with the SSO and might be licensed in other systems, and on top of that they might have "authored" content in the past, for sure in Jira Service Management. It is such a simple thing to fix and yet so incredibly frustrating that it hasn't yet Why? Could please Atlassian justify the inaction, as it cannot be about availability of development resources. Something that I believe would work would be just a setting (that could be enabled via a system property if necessary) to auto-logout unlicensed users, so that they are reverted automatically to "anonymous". I cannot see any big issue with this approach.

              Unassigned Unassigned
              nmason Nick Mason
              Votes:
              387 Vote for this issue
              Watchers:
              261 Start watching this issue

                Created:
                Updated: