• Icon: Bug Bug
    • Resolution: Support Request
    • Icon: Highest Highest
    • None
    • 5.8.16
    • None
    • Tomcat 8, JDK 1.8, postgress 9.3.10

      very similar issue here https://confluence.atlassian.com/display/CONFKB/After+upgrading+Confluence%2C+you+are+unable+to+create+new+pages+or+spaces?focusedCommentId=789095450&#comment-789095450

      However, the workaround doesn't work for us.

      2015-11-12 14:14:40,143 WARN [http-nio-12202-exec-155]
      [common.security.jersey.XsrfResourceFilter]
      passesAdditionalBrowserChecks Additional XSRF checks failed for request:
       https://...../wikis/rest/analytics/1.0¦
       -¦/publish/bulk , origin: null , referrer: http://....../fpfis/wikis/pages/editpage.action , credentials in request: true , allowed via CORS: false
      

      Our server.xml configuration are clean and correct.

      What is strange it works fine with Chrome but not with FF or IE.

      Please any help? Our users don't have Chrome installed by default..

            [CONFSERVER-39885] After upgrading Confluence, Additional XSRF checks failed

            Do you have the issue in chrome when browsing in incongnito? 

            Karel Striegel added a comment - Do you have the issue in chrome when browsing in incongnito? 

            Jason @ FPC added a comment - - edited

            My URL and proxy/scheme parameters are correct. The issue I am running into is that, as you noted only Chrome sends the Origin parameter, and Confluence appears to be relying on that. To be clear.. our confluence setup works perfectly fine when accessed from Chrome, and has the XSRF issue described here in this issue when accessed from FF/IE.

            Jason @ FPC added a comment - - edited My URL and proxy/scheme parameters are correct. The issue I am running into is that, as you noted only Chrome sends the Origin parameter, and Confluence appears to be relying on that. To be clear.. our confluence setup works perfectly fine when accessed from Chrome, and has the XSRF issue described here in this issue when accessed from FF/IE.

            By adding the proxyport and scheme parameters at the AJP Connector port, I was able to solve the XSRF control problem. I didn't set the proxyname parameter because I use two separate URLs.

            There are 2 things to consider:

            • The use of a single URL is recommended, especially for not having a link (absolute) problem in Confluence.
            • IE and Firefox do not pass the header Origin parameter. It is possible to force it to the browser level by a plugin (modify-header for example) with the value of the base URL to solve this problem. Chrome passes this value well and the error is not returned. However, you must use the same URL as the Base URL parameterized in the Confluence general configuration.

            You can also check the header in response X-Frame-Options: SAMEORIGIN.

            I add that this problem also concerns JIRA 6 and 7 and can be resolved in the same way.

            Expecting to have helped you.

            Sébastien Lucchini added a comment - By adding the proxyport and scheme parameters at the AJP Connector port, I was able to solve the XSRF control problem. I didn't set the proxyname parameter because I use two separate URLs. There are 2 things to consider: The use of a single URL is recommended, especially for not having a link (absolute) problem in Confluence. IE and Firefox do not pass the header Origin parameter. It is possible to force it to the browser level by a plugin (modify-header for example) with the value of the base URL to solve this problem. Chrome passes this value well and the error is not returned. However, you must use the same URL as the Base URL parameterized in the Confluence general configuration. You can also check the header in response X-Frame-Options: SAMEORIGIN. I add that this problem also concerns JIRA 6 and 7 and can be resolved in the same way. Expecting to have helped you.

            From what I've seen, this is related to a bug in Confluence, and based on the browser/user agent. If you have information that confirms otherwise (without a doubt), that would be helpful.

            Jason @ FPC added a comment - From what I've seen, this is related to a bug in Confluence, and based on the browser/user agent. If you have information that confirms otherwise (without a doubt), that would be helpful.

            Minh Tran added a comment -

            Dear team-systems / sebastien.lucchini,

            Thanks for raising this issue. I believe this is something that our support team will be able to help you with.
            Could I ask that you create a support ticket on https://support.atlassian.com?
            Once you've done this one of our support engineers will be in touch to work with you in resolving this problem.

            Regards,
            Minh Tran
            Confluence Bugmaster
            Atlassian

            Minh Tran added a comment - Dear team-systems / sebastien.lucchini , Thanks for raising this issue. I believe this is something that our support team will be able to help you with. Could I ask that you create a support ticket on https://support.atlassian.com ? Once you've done this one of our support engineers will be in touch to work with you in resolving this problem. Regards, Minh Tran Confluence Bugmaster Atlassian

            I have the same problem on Confluence 5.10.3.

            I have two URLs to access Confluence.

            Base URL1 = URL1 access : OK

            Base URL2 = URL2 access : KO HTTP 403 XSRF Check Failed

            We don't use the same route.

            I try proxyname, proxyport and scheme on AJP Connector (Tomcat) but don't solve this problem.

            Modify user.agent option on navigator can override this problem : IE, Firefox, Chrome. This resolution is not a good solution.

            I'm looking for a better solution.

            Sébastien Lucchini added a comment - I have the same problem on Confluence 5.10.3. I have two URLs to access Confluence. Base URL1 = URL1 access : OK Base URL2 = URL2 access : KO HTTP 403 XSRF Check Failed We don't use the same route. I try proxyname, proxyport and scheme on AJP Connector (Tomcat) but don't solve this problem. Modify user.agent option on navigator can override this problem : IE, Firefox, Chrome. This resolution is not a good solution. I'm looking for a better solution.

            Seconding the request for a resolution or link. I'm on Confluence 5.10.4.

            Team Systems added a comment - Seconding the request for a resolution or link. I'm on Confluence 5.10.4.

            It would be nice to have a resolution or a link to the support ticket here since others are having the same issue.

            Dana Jansen added a comment - It would be nice to have a resolution or a link to the support ticket here since others are having the same issue.

            We're seeing what appears to be this exact issue, but on the latest stable Confluence 5.9.7 - Firefox users get a XSRF failure, Chrome and Sefari appear to work fine.

            Jason @ FPC added a comment - We're seeing what appears to be this exact issue, but on the latest stable Confluence 5.9.7 - Firefox users get a XSRF failure, Chrome and Sefari appear to work fine.

            William Ing added a comment - - edited

            We have over such messages in less than two weeks, while using version 5.9.2 !

            2016-01-28 09:58:23,618 WARN [http-nio-8090-exec-785] [common.security.jersey.XsrfResourceFilter] passesAdditionalBrowserChecks Additional XSRF checks failed for request: https://in
             -- url: /rest/analytics/1.0/publish/bulk | userName: matthewal
            2016-01-28 09:59:18,639 WARN [http-nio-8090-exec-762] [common.security.jersey.XsrfResourceFilter] passesAdditionalBrowserChecks Additional XSRF checks failed for request: https://in
             -- url: /rest/analytics/1.0/publish/bulk | userName: matthewal
            2016-01-28 10:00:08,674 WARN [http-nio-8090-exec-798] [common.security.jersey.XsrfResourceFilter] passesAdditionalBrowserChecks Additional XSRF checks failed for request: https://in
             -- url: /rest/analytics/1.0/publish/bulk | userName: matthewal
            2016-01-28 10:00:08,677 WARN [http-nio-8090-exec-750] [common.security.jersey.XsrfResourceFilter] passesAdditionalBrowserChecks Additional XSRF checks failed for request: https://in
            

            And these, but considerably less than the previous one, more like 1 for each 100 of the first ones:

            2016-01-28 13:24:43,064 WARN [http-nio-8090-exec-461] [common.security.jersey.XsrfResourceFilter] passesAdditionalBrowserChecks Additional XSRF checks failed for request: https://in
             -- url: /rest/webResources/1.0/resources | userName: matthewal
            2016-01-28 13:24:59,742 WARN [http-nio-8090-exec-782] [common.security.jersey.XsrfResourceFilter] passesAdditionalBrowserChecks Additional XSRF checks failed for request: https://in
             -- url: /rest/webResources/1.0/resources | userName: matthewal
            2016-01-28 13:25:05,470 WARN [http-nio-8090-exec-573] [common.security.jersey.XsrfResourceFilter] passesAdditionalBrowserChecks Additional XSRF checks failed for request: https://in
            

            William Ing added a comment - - edited We have over such messages in less than two weeks, while using version 5.9.2 ! 2016-01-28 09:58:23,618 WARN [http-nio-8090-exec-785] [common.security.jersey.XsrfResourceFilter] passesAdditionalBrowserChecks Additional XSRF checks failed for request: https: //in -- url: / rest /analytics/1.0/publish/bulk | userName: matthewal 2016-01-28 09:59:18,639 WARN [http-nio-8090-exec-762] [common.security.jersey.XsrfResourceFilter] passesAdditionalBrowserChecks Additional XSRF checks failed for request: https: //in -- url: / rest /analytics/1.0/publish/bulk | userName: matthewal 2016-01-28 10:00:08,674 WARN [http-nio-8090-exec-798] [common.security.jersey.XsrfResourceFilter] passesAdditionalBrowserChecks Additional XSRF checks failed for request: https: //in -- url: / rest /analytics/1.0/publish/bulk | userName: matthewal 2016-01-28 10:00:08,677 WARN [http-nio-8090-exec-750] [common.security.jersey.XsrfResourceFilter] passesAdditionalBrowserChecks Additional XSRF checks failed for request: https: //in And these, but considerably less than the previous one, more like 1 for each 100 of the first ones: 2016-01-28 13:24:43,064 WARN [http-nio-8090-exec-461] [common.security.jersey.XsrfResourceFilter] passesAdditionalBrowserChecks Additional XSRF checks failed for request: https: //in -- url: / rest /webResources/1.0/resources | userName: matthewal 2016-01-28 13:24:59,742 WARN [http-nio-8090-exec-782] [common.security.jersey.XsrfResourceFilter] passesAdditionalBrowserChecks Additional XSRF checks failed for request: https: //in -- url: / rest /webResources/1.0/resources | userName: matthewal 2016-01-28 13:25:05,470 WARN [http-nio-8090-exec-573] [common.security.jersey.XsrfResourceFilter] passesAdditionalBrowserChecks Additional XSRF checks failed for request: https: //in

              Unassigned Unassigned
              192309811022 Mohamed Gargouri
              Affected customers:
              0 This affects my team
              Watchers:
              14 Start watching this issue

                Created:
                Updated:
                Resolved: