Tests cannot be started if TEAM Engine is available via HTTPS

[lgoltz]

Setup:

• Reverse proxy is used (Apache2 HTTP server).
• Reverse proxy uses HTTP protocol (mod_proxy and mod_proxy_http) to connect with Tomcat.
• TLS is configured in Apache2 HTTP server.

Workflow:

• Access TEAM Engine via HTTPS.
• Login, select test suite and configure test run (e.g. ets-ogcapi-features).
• Select "start test run".
• Test run does not start. If network analysis is done, it can be observed that not all request are sent via HTTPS.

This issue is not related to Production and Beta instance of OGC. Here, TEAM Engine can be used with HTTPS:

• https://cite.opengeospatial.org/te2/
• https://cite.opengeospatial.org/teamengine/

[dstenger]

@keshav-nangare Can you please analyse the problem?

[dstenger]

@kstegemoller Maybe, you can help us here. Do you have any hints when setting up the reverse proxy with SSL targeting TEAM Engine?

[kstegemoller]

@dstenger @lgoltz We use libapache2-mod-jk for production and beta.

Have you set both ProxyPass and ProxyPassReverse correctly? Do you have it set for all required URL paths?

[elasticlabs]

Hi, I experience the same issue with NGinx reverse proxy.

Here's my configuration file :

server {
        server_name teamengine.elasticlabs.co;
        listen 80 ;

        access_log /var/log/nginx/tomcat-access.log;
        error_log /var/log/nginx/tomcat-error.log;

        location / {
                proxy_set_header X-Forwarded-Host $host;
                proxy_set_header X-Forwarded-Server $host;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header X-Forwarded-Proto https;
                proxy_pass http://teamengine:8080/;
        }

[elasticlabs]

Adding this line in server blaock helps, but the test.jsp inner frame with test execution cannot find the server, seeking the backend IP or name as configured in the proxy_pass directive.

        add_header Content-Security-Policy upgrade-insecure-requests;

[elasticlabs]

OK I think it should be quickly fixed for NGinx.

Here's a working example.
The `` header is mandatory in the server block.

# If we receive X-Forwarded-Proto, pass it through; otherwise, pass along the
# scheme used to connect to this server
map $http_x_forwarded_proto $proxy_x_forwarded_proto {
  default $http_x_forwarded_proto;
  ''      $scheme;
}
# If we receive X-Forwarded-Port, pass it through; otherwise, pass along the
# server port the client connected to
map $http_x_forwarded_port $proxy_x_forwarded_port {
  default $http_x_forwarded_port;
  ''      $server_port;
}
# If we receive Upgrade, set Connection to "upgrade"; otherwise, delete any
# Connection header that may have been passed to this server
map $http_upgrade $proxy_connection {
  default upgrade;
  '' close;
}
# Apply fix for very long server names
server_names_hash_bucket_size 128;
# Default dhparam
ssl_dhparam /etc/nginx/dhparam/dhparam.pem;
# Set appropriate X-Forwarded-Ssl header
map $scheme $proxy_x_forwarded_ssl {
  default off;
  https on;
}
gzip_types text/plain text/css application/javascript application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript;
log_format vhost '$host $remote_addr - $remote_user [$time_local] '
                 '"$request" $status $body_bytes_sent '
                 '"$http_referer" "$http_user_agent"';
access_log off;
resolver 127.0.0.11;
# HTTP 1.1 support
proxy_http_version 1.1;
proxy_buffering off;
proxy_set_header Host $http_host;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $proxy_connection;
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 $proxy_x_forwarded_proto;
proxy_set_header X-Forwarded-Ssl $proxy_x_forwarded_ssl;
proxy_set_header X-Forwarded-Port $proxy_x_forwarded_port;
# Mitigate httpoxy attack (see README for details)
proxy_set_header Proxy "";
server {
        server_name _; # This is just an invalid value which will never trigger on a real hostname.
        listen 80;
        access_log /var/log/nginx/access.log vhost;
        return 503;
}
# server blocks definition
server {
        server_name teamengine.elasticlabs.co;
        listen 80 ;
        access_log /var/log/nginx/access.log vhost;
        **add_header Content-Security-Policy upgrade-insecure-requests;**

        # Tomcat behind reverse proxy -> https://clouding.io/hc/en-us/articles/360010691359-How-to-Install-Tomcat-with-Nginx-as-a-Reverse-Proxy-on-Ubuntu-18-04
        location / {
          proxy_pass http://teamengine:8080/;
          proxy_set_header X-Forwarded-Host $host;
          proxy_set_header X-Forwarded-Server $host;
          proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
          proxy_set_header X-Forwarded-Proto $scheme;
          proxy_set_header Host $http_host;
          proxy_set_header X-Real-IP $remote_addr;

        }
}

[dstenger]

Might be related to #501.

[ghobona]

Requested a discussion with the OGC Infrastructure Office.

[dstenger]

Further observation is that when logging in from TEAM Engine landing page accessed via HTTPS (e.g. https://cite.ogc.org/teamengine/), the site displayed after logging in is requested via HTTP.
This behavior is probably related to the problem described in this issue.

[dstenger]

@bpross-52n Can you please document your proposed solution in this issue?

[bpross-52n]

The proposed solution is to use the x-forwarded-proto header. This needs to be set by the proxy/load balancer in front of the teamengine. If the header is present, the value of the header is used, otherwise http.

[ghobona]

@kstegemoller We now have a solution for this, based on the x-forwarded-proto header. @bpross-52n will contact you about arranging a telecon to discuss configuration of the server.

[elasticlabs]

Hi everyone,

AFAIK and tested, those fixes won't be enough to properly serve all required assets and make TEAMengine behave properly.

Here's a field proven method used with my students : Nginx proxy config block
# Required in the server {} block to fix unproper HTTPS handling within TEAMEngine
add_header Content-Security-Policy upgrade-insecure-requests;

So, unless I missed part of the fixes and issues information, if you reference in TE code assets using http without 's' explicitely, the reverse proxy needs to be told a request upgrade to enable in-page frame and log windows to operate properly.
You can try a running instance here : TEAMengine demo instance.

Best regards