Wrong URL generation

Help / Discuss
#1

Next problem: URLs.
I have no idea anymore to let our xwiki generate the correct urls.

Setup:

xwiki-docker → nginx-proxy → cloudfront

I tried to set the “X-Forwared-Proto” and “X-Scheme” head values in nginx and/or cloudfront, but on a lot of links I get http://:80 or just “http://hostname”, mainly when accessing the REST-API the responses contains a lot of http://:80 links.

I set in xwiki config the wiki.url.protocol to https, set the xwiki.home to the host with https, nothing helps.

Any ideas, what I can do here? (yes I tried to setup it in wiki-properties, too)

R

#2

Step 1: before adding cloudfront - make sure your xwiki-docker <-> nginx-proxy is working correctly. Turn off cloudfront and then retest. I suspect this is where your problem is.

Step 2: if it is working properly, then enable cloudfront.

#3

Hm, what do you mean with “working correctly” - it does work. eg, I can access all wikis, the internal url generation is ok, otherwise it wouldn’t be usable.

As I said, the only thing are urls in api-responses and some urls generated for chrome console are created wrong.

But I will try to setup a direct setup to nginx proxy

#4

By “working correctly” I mean that everything is working exactly the way you expect it to.

If something is not right, like some urls incorrectly generated, then it is not “working correctly”.

When trying to solve a problem, I always try to isolate the problem down to the smallest possible set of choices and conditions. Otherwise I might end up trying to look in the wrong direction. In your case, you’ve not provided a lot of information that would allow someone to figure out what the problem is, except for people who have a lot more experience with solving xwiki installation problems.

#5

Ok, did it. Direct connection to nginx proxy.

server {
    listen       80;
    listen  [::]:80;
    server_name kb.xxxx.com wiki.xxxxx.com devops.xxxxx.com;
    return 301 https://$host$request_uri;
}

server {
    server_name kb.xxxx.com wiki.xxxx.com devops.xxxx.com;
    include /etc/nginx/conf.d/ssl_config_standard;
    client_max_body_size 5G;

    location / {
        proxy_pass http://xwiki:8080;
        proxy_set_header Host $host;
        proxy_http_version 1.1;
        proxy_set_header   X-Real-IP $remote_addr;
        proxy_set_header   Upgrade $http_upgrade;
        proxy_set_header   Connection 'upgrade';
        proxy_cache_bypass $http_upgrade;
        proxy_set_header X-Scheme $scheme;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Result:

  • the save button when edit user rights of a wiki tries to submit to https://wiki.xxxx.com:80 - failes of course
  • in dev-console I see a lot of malformed urls this way. eg https://:80 - when it would be “http://:80” it would work because then the redirect would happen.

and this drives me crazy because I don’t know how to disable that xwiki is appending the port. I set the port “443” in wiki administration and enforced ssl … I tried it within the wiki properties - them are completely ignored.

So I have no ideas anymore. Xwiki version is 14.3

#6

I have a similar configuration. I have an nginx ssl proxy on 1 machine connecting to tomcat directly on another machine.

Here are the relevant settings inside nginx on my setup:

        location / {
        proxy_set_header Accept-Encoding "";
        sub_filter 'https://wiki.example.com:80/' 'https://wiki.example.com/' ;
        sub_filter_once off;
                proxy_pass http://10.10.1.100/; # internal ip address of the tomcat running on port 80, not 8080
                proxy_set_header Host $host;
                proxy_set_header X-Forwarded-Host $host;
                proxy_set_header X-Forwarded-Server $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_redirect http://wiki.example.com https://wiki.example.com;
        }

Now what are these settings, and why did I set them? Honestly, I forget the details as it was several years ago. Searching the forums here might turn up the answer, but basically it had something to do with rewriting the urls coming back from Tomcat to Nginx so the client would receive the correct urls.

Maybe this will help.

#7

Yes, nice idea, I put

        sub_filter 'https://$host:80/' 'https://$host/';
        sub_filter_once off;

into nginx configuration. This is a nice workaround, indeed - even it will not solve the underlying problem of wrong url generation (I think it is more a tomcat problem).

Many thanks for the idea!