Failed to retrieve extension data.Server not responding site

Help / Discuss
16

Late to the party here, but I would argue this is not “resolved”. The OP found a hack way to get around the installation failing. @sfloydt65 asked how to avoid this error during a fresh install here, and 5 years later his question has not been answered, so here I am with the same problem :frowning:

So we know that entering a browser’s developer mode and manually adding <meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests"> to the HTML <head></head> tag will allow the install to progress, but how to avoid this error in the first place so this manual edit of HTML in a browser’s developer mode isn’t necesssary? Also, I don’t know much about XWiki at this point, so I don’t know if this is a deeper problem that will pop up later in other aspects of the application, or if it is limited to the installation process. It would be nice to better understand that.

Update 1:

I think I have a good solution to this problem that should prevent it from happening in similar situations with other applications in the future. I’m running XWiki in a Docker container behind an Nginx reverse proxy which is also in a Docker container, so this solution might not apply to everyone. The solution was to add the Content-Security-Policy upgrade-insecure-requests header in 3 places. Here is a minimal example of my Nginx config before applying the solution:

server {
    listen 80 default_server;

    # Match requests with and with www, and with and without a subdomain
    # If a request has a subdomain, it will be stored in the $subdomain variable
    server_name ~^(www\.)?(?<subdomain>.+?)?\.?example\.com$;
    server_tokens off;

    # Redirect all HTTP traffic to HTTPS
    location / {
        if ($subdomain) {
            return 301 "https://$subdomain.example.com$request_uri";
        }
        return 301 "https://example.com$request_uri";
    }
}

server {
    listen 443 ssl default_server;
    http2 on;

    server_name ~^(www\.)?(?<subdomain>.+?)?\.?example\.com$;
    server_tokens off;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    # Disable TLS 1.0, TLS 1.1, and TLS 1.2 because they are old and insecure
    ssl_protocols TLSv1.3;

    location / {
        set $proxy_pass "";

        set $xwiki_container "xwiki";
        set $xwiki_subdomain "wiki";
        set $xwiki_port "8080";
        if ($subdomain = $xwiki_subdomain) {
            set $proxy_pass "http://$xwiki_container:$xwiki_port$request_uri";
        }

        if ($proxy_pass = "") {
            return 403;
        }

        # Proxy the request to the corresponding Docker container based on subdomain
        proxy_pass $proxy_pass;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

And after applying the solution:

server {
    listen 80 default_server;

    # Match requests with and with www, and with and without a subdomain
    # If a request has a subdomain, it will be stored in the $subdomain variable
    server_name ~^(www\.)?(?<subdomain>.+?)?\.?example\.com$;
    server_tokens off;

    # For services that write their own URLs and default them to being HTTP, request that they be HTTPS
    add_header Content-Security-Policy upgrade-insecure-requests;

    # Redirect all HTTP traffic to HTTPS
    location / {
        if ($subdomain) {
            return 301 "https://$subdomain.example.com$request_uri";
        }
        return 301 "https://example.com$request_uri";
    }
}

server {
    listen 443 ssl default_server;
    http2 on;

    server_name ~^(www\.)?(?<subdomain>.+?)?\.?example\.com$;
    server_tokens off;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    # Disable TLS 1.0, TLS 1.1, and TLS 1.2 because they are old and insecure
    ssl_protocols TLSv1.3;

    # For services that write their own URLs and default them to being HTTP, request that they be HTTPS
    add_header Content-Security-Policy upgrade-insecure-requests;

    location / {
        set $proxy_pass "";

        set $xwiki_container "xwiki";
        set $xwiki_subdomain "wiki";
        set $xwiki_port "8080";
        if ($subdomain = $xwiki_subdomain) {
            set $proxy_pass "http://$xwiki_container:$xwiki_port$request_uri";
        }

        if ($proxy_pass = "") {
            return 403;
        }

        # Proxy the request to the corresponding Docker container based on subdomain
        proxy_pass $proxy_pass;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header Content-Security-Policy upgrade-insecure-requests;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
    }
}

A better solution to this problem I think would be for the Docker image to support defining xwiki.home as an environment variable in the Docker config instead of having to define it in the xwiki.cfg file. Then XWiki should look at the protocol and port used for that environment variable (http/https) and honor it when building URLs.

Optimally all the variables in xwiki.cfg would be exposed as environment variables to Docker :wink: