Unable to run setup on HTTPS + proxy'd sub-path

[vollmerk]

We run IPT behind an NGINX proxy over SSL in a sub-path and when submitting the setup form, the HTTP POST is sent with the correct data, but the application does not think it received anything

https://example.com/ipt (NGINX entry point)
Proxy to
http://127.0.0.1:8080 (IPT Tomcat instance)

baseURL is set correctly, as all of the image urls are generated correctly

I did note that the <form action="setup2.do" does not include ${baseURL}, adding that manually doesn't make any difference.

...

I also note that there appears to be a missing referenced bootstrap file

DevTools failed to load source map: Could not load content for https://example.com/ipt/js/bootstrap/bootstrap.bundle.min.js.map: HTTP error: status code 404, net::ERR_HTTP_RESPONSE_CODE_FAILURE

[pieterprovoost]

The config below works for me, as long as I complete the setup on http://example.com:8080. You may need to change proxy_pass if you are not using Docker or deploying in the Tomcat root.

server {
    server_name ipttest.obis.org;

    location /ipt {
        proxy_set_header X-Real-IP  $remote_addr;
        proxy_set_header X-Forwarded-For $remote_addr;
        proxy_set_header Host $host;
        proxy_pass http://localhost:8080/;
    }

    listen [::]:443 ssl ipv6only=on; # managed by Certbot
    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/ipttest.obis.org/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/ipttest.obis.org/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}

server {
    if ($host = ipttest.obis.org) {
        return 301 https://$host$request_uri;
    } # managed by Certbot
    listen 80 default_server;
    listen [::]:80 default_server;
    server_name ipttest.obis.org;
    return 404; # managed by Certbot
}

[vollmerk]

Thanks, so Proxy'd ${baseURL}/ipt and even direct http://localhost:8080/ipt/ and http://localhost:8080/ are not working for me on the newest release.

My browser is Firefox (latest version no plugins/blocking) I'm using the WAR with tomcat 7.x whenever I submit setup2.do it returns to the same page and claims that nothing has been submitted. I checked and confirmed post data is being sent from firefox. So this has got to be an app problem.

When's the last time you setup IPT from scratch, and are you using the WAR?

[pieterprovoost]

@vollmerk I tried with the latest version (2.5.1) using Docker, as well as in a Tomcat subfolder like you did. For the latter case I had to change my config to proxy_pass http://localhost:8080/ipt/;.

This is what the POST request looks like, so the setup2.do request redirects to setup3.do taking into account the public URL.

[vollmerk]

What version of tomcat are you using? Yeah I never get the redirect to setup3, just a kick back to setup2 claiming I submitted none of the values.

[vollmerk]

tomcat-7.0.76-16.el7_9.noarch
java-1.8.0-openjdk-headless-1.8.0.292.b10-1.el7_9.x86_64

Is what I'm running.

[pieterprovoost]

I tested with Tomcat 8.5 on Java 8 before, but I did a quick check with a (Dockerized) Tomcat 7.0.76 on OpenJDK 8 and that worked fine as well. If you do not need your Tomcat for other purposes you may want to look into the IPT Docker image, it works like a charm.

[vollmerk]

So I managed to get this going using the docker container, but I noticed some additional things

• I could only get the setup page to work if I tunneled the localhost URL and accessed the container directly, through the NGINX proxy seemed to produce errors
• We already had something on 8080 so I had Docker publishing it to 8082, this also caused errors as when running setup2.do it appeared to be confirming the URL, but it was using it's own internal understanding of self, so it didn't work until I set it to http://127.0.0.1:8080. Then hit save, then manually edit the ipt.properties file and set it back to http://127.0.0.1:8082
• Step 3 worked, and then I had to go back in and change the URL again to the real Nginx proxy URL and it works as expected even over HTTPS

So there's definitely some overly aggressive error checking, and non-proxy/path friendly code during the setup

[MattBlissett]

Might the change suggested here help: #1470 (comment)

[vollmerk]

@MattBlissett - That's the opposite problem I have it running on / and proxy'd from /ipt. Either way I forced the cookie path and the problems persist.

It's down to I can get it to run, when /ipt/login.do is run it accepts the authentication, sets the cookie properly but then re-directs to / instead of /ipt. / is a different application :D

I haven't looked at the code yet, but I'm guessing that the login processing doesn't account for the defined path and just redirects to / on success.

[MattBlissett]

Pieter's Nginx + Docker configuration works for me with the current snapshot, including with Docker exposing port 8082.

Using proxy_pass http://localhost:8080/ipt/;, it also works with an IPT deployed in Tomcat at /ipt.

I've added the Nginx configuration to the documentation.

I think it helps to have the IPT's internal path (e.g. /ipt/ or /) the same as the external path, to avoid having to configure the webserver to change this, including for cookies. This is easy for Tomcat (deploy as ROOT.war), but would require rebuilding the Docker image if the default / isn't suitable.

[MattBlissett]

I think this is improved for 2.5.2.

(The missing Bootstrap file is for Javascript debugging, it's not included so the error is expected.)