Knowledge base articles cannot be displayed in the Service Desk customer portal (error: "Refused to display")

お困りですか?

アトラシアン コミュニティをご利用ください。

コミュニティに質問

プラットフォームについて: Server と Data Center のみ - この記事は、サーバーおよびデータセンター プラットフォームのアトラシアン製品にのみ適用されます。

要約

Knowledge base articles cannot be displayed in the Service Desk customer portal iframe:

The error "refused to connect" might be displayed in the UI:

 

Either of the following error is thrown in the browser console:

  • Error 1:

    Refused to display 'XXXXXXXXXXX/plugins/servlet/remotepageview?pageId=XXXXXX' in a frame because it set 'X-Frame-Options' to 'deny'.
  • Error 2

    Refused to display 'XXXXXXXXXXX/plugins/servlet/remotepageview?pageId=XXXXXX' in a frame because it set 'X-Frame-Options' to 'sameorigin'.

環境

原因

Confluence comes out-of-the-box with the X-Frame-Options header set to sameorigin, as per the KB article Confluence page does not display in an iframe. This header was added in Confluence 5.18.15 to implement the feature request UI Redressing (Clickjacking).

The expected behavior in a fresh vanilla Confluence Server instance (without any customization nor reverse proxy), is described below:

  • When accessing most Confluence URLs, the X-Frame-Options header is set to sameorigin
  • When accessing some specific Confluence URLs such as the ones with the format <CONFLUENCE_BASE_URL>/plugins/servlet/remotepageview?pageId=XXXXX, the X-Frame-Options header is not set. The reason why URLs with the pattern /plugins/servlet/remotepageview?pageId= do not have the X-Frame-Options header set is to allow external applications such as Service Desk to display Confluence KB article in an iFrame.


The X-Frame-Options header can be customized and overwritten in various ways:

  • Via a reverse proxy, if Confluence is configured behind one
  • By adding a security filter in either of the 2 web.xml files in located in the Confluence installation folder, as these 2 locations:
    • <confluence-installation-folder>/conf/web.xml
    • <confluence-installation-folder>/confluence/WEB-INF/web.xml

If this header is set to either sameorigin or deny by a proxy server or a security filter regardless of the type of Confluence URL, then it will become impossible to display any Confluence KB article in the Service Desk portal, since this header will prevent the content of this URL from being displayed in an iFrame.

There are 2 common reasons why Confluence KB articles can't be displayed in the Customer Portal:

  • Root cause 1: Confluence is running behind a reverse proxy which is overwriting the X-Frame-Options header 
  • Root cause 2: One of the 2 web.xml file is configured with a security filter

To check if either a reverse proxy server or a filter in web.xml file is causing the issue, go to the Diagnosis section below.

診断

  • Record a HAR file while replicating the KB display issue in the Service Desk portal
  • Open the HAR file, and look for the URL which has the format <CONFLUENCE_BASE_URL>/plugins/servlet/remotepageview?pageId=XXXXXX
  • Check if the X-Frame-Options header is set, and what value it is set to. If it is set to either sameorigin or deny, then this KB article is relevant to the issue you are facing:


Now, the question is: what is setting this header?

Verifying Root cause 1 (Reverse Proxy server)

  • If Confluence is running behind a reverse proxy, try to bypass the reverse proxy by following the steps in How to bypass a proxy to test network connectivity
  • Log into your Confluence instance by using the URL http://<CONFLUENCE_IP_ADDRESS>:<UN_PROXIED_PORT>
  • In the same browser, try to open the problematic Confluence URL /plugins/servlet/remotepageview?pageId=XXXXXX which had the X-Frame-Options header set to sameorigin or deny
    • (warning) For this test, make sure to use http://<CONFLUENCE_IP_ADDRESS>:<UN_PROXIED_PORT> as Confluence's Base URL
  • If the X-Frame-Options header is no longer set to sameorigin nor deny (it should not be set at all), then we know that the problem was from the reverse proxy server

Verifying Root cause 2 (security filter in one of the two web.xml file)

  • Open the 2 following files in a text editor
    • <confluence-installation-folder>/conf/web.xml
    • <confluence-installation-folder>/confluence/WEB-INF/web.xml
  • Look for the XML tag <filter-name>httpHeaderSecurity</filter-name>
  • Check if this tag is configured similarly to any of the examples listed below:
    • 例 1

      <filter>
       <filter-name>httpHeaderSecurity</filter-name>
       <filter-class&amp;amp;gt;org.apache.catalina.filters.HttpHeaderSecurityFilter</filter-class&amp;amp;gt;
       <async-supported>true</async-supported>
       <init-param>
       <param-name>antiClickJackingEnabled</param-name>
       <param-value>true</param-value>
       </init-param>
       <init-param>
       <param-name>antiClickJackingOption</param-name>
       <param-value>DENY</param-value>
       </init-param>
       </filter>
      
        <filter-mapping>
              <filter-name>httpHeaderSecurity</filter-name>
              <url-pattern>/*</url-pattern>
              <dispatcher>REQUEST</dispatcher>
        </filter-mapping>
    • 例 2

      <filter>
       <filter-name>httpHeaderSecurity</filter-name>
       <filter-class&amp;amp;gt;org.apache.catalina.filters.HttpHeaderSecurityFilter</filter-class&amp;amp;gt;
       <async-supported>true</async-supported>
       <init-param>
       <param-name>antiClickJackingEnabled</param-name>
       <param-value>true</param-value>
       </init-param>
       <init-param>
       <param-name>antiClickJackingOption</param-name>
       <param-value>SAMEORIGIN</param-value>
       </init-param>
       </filter>
      
        <filter-mapping>
              <filter-name>httpHeaderSecurity</filter-name>
              <url-pattern>/*</url-pattern>
              <dispatcher>REQUEST</dispatcher>
        </filter-mapping>
    • 例 3

      <filter>
              <filter-name>httpHeaderSecurity</filter-name>
              <filter-class&amp;gt;org.apache.catalina.filters.HttpHeaderSecurityFilter</filter-class&amp;gt;
              <async-supported>true</async-supported>
      </filter>
      
        <filter-mapping>
              <filter-name>httpHeaderSecurity</filter-name>
              <url-pattern>/*</url-pattern>
              <dispatcher>REQUEST</dispatcher>
        </filter-mapping>
  • If you see any variation of the examples listed above, follow the steps below:

    • Remove the filter completely from any of the 2 web.xml files
    • Re-start the Confluence application
    • Log into Confluence
    • In the same browser, try to open the problematic Confluence URL /plugins/servlet/remotepageview?pageId=XXXXXX which had the X-Frame-Options header set to sameorigin or deny
    • If the X-Frame-Options header is no longer set to sameorigin nor deny (it should not be set at all), then we know that the problem was from the security filter configured in 1 or both of the 2 web.xml files

ソリューション

Root cause 1 (reverse proxy server):

Remove any configuration in your reverse proxy server that sets the X-Frame-Options header.

例:

  • If you are using Apache, check if the following configuration is found in the file httpd.conf. If you find such configuration, remove it:

    Header always append X-Frame-Options SAMEORIGIN
    OR
    Header always append X-Frame-Options DENY
  • If you are using Nginx, check it if is configured with the header shown below. If you find such configuration, remove it:

    add_header X-Frame-Options "SAMEORIGIN";
    OR
    add_header X-Frame-Options "DENY";

Root cause 2 (security filter in web.xml):

Remove any security filter configured in either of these 2 files:

  • <confluence-installation-folder>/conf/web.xml
  • <confluence-installation-folder>/confluence/WEB-INF/web.xml

最終更新日: 2021 年 10 月 1 日

この内容はお役に立ちましたか?

はい
いいえ
この記事についてのフィードバックを送信する
Powered by Confluence and Scroll Viewport.