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

Turning off Anti-XSRF protection for comments has no effect

    • Icon: Bug Bug
    • Resolution: Won't Fix
    • Icon: Low Low
    • None
    • 4.2.5, 4.2.12, 4.2.13, 5.1.3
    • None
    • Juniper VPN

      Turning off Anti-XSRF protection for comments does not have the desired effect. Even if the setting is turned off (verified that the setting is saved in the BANDANA table), adding comments is not possible, due to an XSRF warning. This is also covered in more details on this KB: https://confluence.atlassian.com/x/5gfuEQ

            [CONFSERVER-26485] Turning off Anti-XSRF protection for comments has no effect

            pdr added a comment -

            Awesome, @dblack, that does indeed fix the issue for us. Thank you very much for following up on this!

            pdr added a comment - Awesome, @dblack, that does indeed fix the issue for us. Thank you very much for following up on this!

            pete.ryland since confluence 5.8.14 (when CONF-39266 was fixed) you should be able to whitelist the other origins that confluence might be used as and by allowing incoming connections from those origins the csrf origin rest check will pass. See https://confluence.atlassian.com/doc/configuring-the-whitelist-381255821.html for information on configuring the whitelist in confluence.

            David Black added a comment - pete.ryland since confluence 5.8.14 (when CONF-39266 was fixed) you should be able to whitelist the other origins that confluence might be used as and by allowing incoming connections from those origins the csrf origin rest check will pass. See https://confluence.atlassian.com/doc/configuring-the-whitelist-381255821.html for information on configuring the whitelist in confluence.

            Minh Tran added a comment -

            Hi All,

            Thanks for taking the time to raise and comment on this issue.
            I would like to close this issue as won't fix given that we are likely to remove the disable xsrf for comments functionality anyway.

            Regards
            Minh Tran
            Confluence Bugmaster
            Atlassian

            Minh Tran added a comment - Hi All, Thanks for taking the time to raise and comment on this issue. I would like to close this issue as won't fix given that we are likely to remove the disable xsrf for comments functionality anyway. Regards Minh Tran Confluence Bugmaster Atlassian

            pdr added a comment -

            @dblack: Indeed. However, it should be possible for confluence to check that the domains match. If you look at that log, it appears that confluence has used the default domain for the XSRF check rather than the domain of the actual request. If that's fixed, it'll probably fix the problem for the Juniper guys as well.

            It's technically possible to solve in the apache config as well. However, that would involve re-writing the CORS headers before passing to confluence, which is possible, but less secure unless I also then add in CORS checks to my mod_rewrite rules. Again, possible, but probably not the right solution.

            As for the reason why there are multiple domains on the one confluence instance, that decision pre-dates my time at this company, but I can imagine the conversation went something like:
            CEO: Hey, is it possible to put the documentation space on a different subdomain, like company XYZ does it?
            Enthusiastic can-do Dev, who looked after the server: Oh, but it's already all on the one server, and I don't want to set up another one, it took me a week just to install Linux! But I was reading about mod_rewrite the other day, and I think it should be possible with that, although I don't know if that will play nicely with mod_proxy or if I should use mod_j...
            CEO: Excellent. Make it so. Today please.
            (some time later)
            Less-enthusiastic can-do Dev: Boy sysadmin is tricky, why can't devs make life easier for sysadmins.
            (some time later)
            Dev: I don't have enough time to manage our server and do coding.
            CEO: Let's just hire a sysadmin, they can sort it out.
            (some time later)
            Sysadmin: Oh! Mr Hart, what a mess!

            pdr added a comment - @dblack: Indeed. However, it should be possible for confluence to check that the domains match. If you look at that log, it appears that confluence has used the default domain for the XSRF check rather than the domain of the actual request. If that's fixed, it'll probably fix the problem for the Juniper guys as well. It's technically possible to solve in the apache config as well. However, that would involve re-writing the CORS headers before passing to confluence, which is possible, but less secure unless I also then add in CORS checks to my mod_rewrite rules. Again, possible , but probably not the right solution. As for the reason why there are multiple domains on the one confluence instance, that decision pre-dates my time at this company, but I can imagine the conversation went something like: CEO : Hey, is it possible to put the documentation space on a different subdomain, like company XYZ does it? Enthusiastic can-do Dev, who looked after the server : Oh, but it's already all on the one server, and I don't want to set up another one, it took me a week just to install Linux! But I was reading about mod_rewrite the other day, and I think it should be possible with that, although I don't know if that will play nicely with mod_proxy or if I should use mod_j... CEO : Excellent. Make it so. Today please. (some time later) Less-enthusiastic can-do Dev : Boy sysadmin is tricky, why can't devs make life easier for sysadmins. (some time later) Dev : I don't have enough time to manage our server and do coding. CEO : Let's just hire a sysadmin, they can sort it out. (some time later) Sysadmin : Oh! Mr Hart , what a mess!

            pete.ryland that xsrf failure as you can see is caused by two different domain names being used for the one confluence instance. Is there a reason why you have two (or more) different domain names for the one confluence instance?

            David Black added a comment - pete.ryland that xsrf failure as you can see is caused by two different domain names being used for the one confluence instance. Is there a reason why you have two (or more) different domain names for the one confluence instance?

            pdr added a comment -

            This is also affecting us, but we are not using a VPN. However, we have a fairly convoluted apache setup, with multiple domain names all being served by the one confluence instance (academy.magnolia-cms.com, documentation.magnolia-cms.com and wiki.magnolia-cms.com) which redirect to the relevant spaces. I'm attempting to fix this by forcing various headers through the proxy, but it would be nice to turn off this extra protection in the mean time. Our current workaround is for editors to modify the URL to the canonical one if they encounter errors.

            The errors we get in the confluence log look like this:

            2015-10-19 22:14:36,272 WARN [http-nio-8091-exec-22] [common.security.jersey.XsrfResourceFilter] passesAdditionalBrowserChecks Additional XSRF checks failed for request: https://wiki.magnolia-cms.com/rest/analytics/1.0/publish/bulk , origin: https://academy.magnolia-cms.com , referrer: https://academy.magnolia-cms.com/display/MA/Magnolia+Academy , credentials in request: true , allowed via CORS: false
             -- referer: https://academy.magnolia-cms.com/display/MA/Magnolia+Academy | url: /rest/analytics/1.0/publish/bulk | userName: pdr
            

            pdr added a comment - This is also affecting us, but we are not using a VPN. However, we have a fairly convoluted apache setup, with multiple domain names all being served by the one confluence instance (academy.magnolia-cms.com, documentation.magnolia-cms.com and wiki.magnolia-cms.com) which redirect to the relevant spaces. I'm attempting to fix this by forcing various headers through the proxy, but it would be nice to turn off this extra protection in the mean time. Our current workaround is for editors to modify the URL to the canonical one if they encounter errors. The errors we get in the confluence log look like this: 2015-10-19 22:14:36,272 WARN [http-nio-8091-exec-22] [common.security.jersey.XsrfResourceFilter] passesAdditionalBrowserChecks Additional XSRF checks failed for request: https: //wiki.magnolia-cms.com/ rest /analytics/1.0/publish/bulk , origin: https://academy.magnolia-cms.com , referrer: https://academy.magnolia-cms.com/display/MA/Magnolia+Academy , credentials in request: true , allowed via CORS: false -- referer: https: //academy.magnolia-cms.com/display/MA/Magnolia+Academy | url: / rest /analytics/1.0/publish/bulk | userName: pdr

            Stian Espe added a comment -

            Hi David,

            Our global IT dept edited our firewall yesterday, and we got it working by applying the workaround described in https://confluence.atlassian.com/pages/viewpage.action?pageId=300812262.

            Stian Espe added a comment - Hi David, Our global IT dept edited our firewall yesterday, and we got it working by applying the workaround described in https://confluence.atlassian.com/pages/viewpage.action?pageId=300812262 .

            David Black added a comment - - edited

            The confluence setting to disable xsrf protection on comments does not apply to rest resources involving comments. It only applies to the doaddcomment and doeditcomment actions in confluence. Also, it is likely the ability to disable xsrf checking for comments will be removed in a future release.

            David Black added a comment - - edited The confluence setting to disable xsrf protection on comments does not apply to rest resources involving comments. It only applies to the doaddcomment and doeditcomment actions in confluence. Also, it is likely the ability to disable xsrf checking for comments will be removed in a future release.

            Stian Espe added a comment -

            I got the same problem, on our setup with Juniper firewalls.
            Any progress on this issue?

            Stian Espe added a comment - I got the same problem, on our setup with Juniper firewalls. Any progress on this issue?

              Unassigned Unassigned
              pkoczan Peter Koczan (Inactive)
              Affected customers:
              4 This affects my team
              Watchers:
              13 Start watching this issue

                Created:
                Updated:
                Resolved: