Hard coded request for HTTP in Designer Launcher even if gateway set up for HTTPS

Ignition Early Access
#1

Hi,

Using a reverse proxy so not using ignitions SSL settings or force secure redirect. I am however forcing redirect for https for any incoming http requests.
Unfortunately the designer launcher is requesting http://mydomain.com/StatusPing and it does not appear to be happy with a returned HTTPS page.
I have tested this with a normal ignition install using ignition’s SSL and force secure redirect, and although the force secure redirect says this: When enabled, and if SSL / TLS is enabled, all http traffic will be redirected to its https counterpart. If you go to the ignition install using http:// and domain.com/StatusPing, this is returned as http, and not redirected to https.
I do not want any http to ever be returned, I believe this is a problem in the Designer Launcher and probably the client launcher.

This causes the designer not to launch as the designer launcher is first checking for a http:// returned gateway status of running before moving on, even though the gateway is running and everything is fine.

I assume this should be fixed, as we should be able to run the gateway using only https, whether using ignitions built in ssl tools or a reverse proxy to handle the ssl.

16
162400×1214 1.18 MB

Mobile application
#2

What version of the launcher are you using? Your URL is public, when I attempted to add it and launch I didn’t see any HTTP traffic, but it did fail for a different reason, which is that the server is returning a 307 Temporary Redirect for https://demo.roesleinsystems.com:443/main/StatusPing

update: not sure if this is the proxy or Ignition doing the redirect. Seems like it’s redirecting to http://demo.roesleinsystems.com/StatusPing

#3

Using launcher 1.0.11.
I’m using Caddy2 for reverse proxy, which I admit I haven’t used before so for me is untested with Ignition. I’m going to install NGINX now and see what happens there, as I know that reverse proxy works, or has in the past.

#4

I don’t think the launcher is the problem here. I’m a little out of my area here, but I think it’s the URL redirect/rewrite logic in the Ignition gateway.

A redirect to remove the “main” from the URL happens, but I think at this point the incoming request is just http, since it’s from the reverse proxy and you presumably do not have SSL enabled in Ignition or force http redirects enabled, so the URL gets rewritten to http://demo.roesleinsystems.com/StatusPing and returned in a 307 to the launcher, which correctly rejects it because the protocol was downgraded from its point of view.

and fwiw, since you observed this, the StatusPing servlet is exempt from the forced HTTPS redirect for <reasons TBD>

2 Likes
#5

OK, that kinda makes sense. I do not have SSL enabled or force redirects enabled, as that is all handled in the reverse proxy. I’ve a feeling Nginx will display the same characteristics then. I’ll do some more testing and see what I can find out. It does seem that it is ignition doing the 307 redirect, when I use the direct link to http://demo.roesleinsystems.com/StatusPing the proxy returns HTTPS and a 308 redirect, as is correct.
I can hopefully handle the 307 redirect in the proxy before it gets back to the designer launcher.

#6

If nobody who has set up nginx comments here over the weekend I’ll ask around on Monday. I don’t know what the usual setup looks like.

1 Like
#7

Thanks Kevin for your assistance, I have managed to get it working by using the proxy to do the redirect from /main/StatusPing to /StatusPing rather than letting ignition handle it. I’m not sure really if this is a bug or just an extra step we’ll need to do for reverse proxies going forwards. Hopefully this thread will help anyone else who runs into this problem.

#8

Thanks @Kevin.Herron and @accyroy. I was able to confirm the same as you had that a request towards /main/StatusPing was the culprit. I’ve got the same setup in Traefik and was able to mitigate it using the same strategy by applying my container labels (running with Docker) like such:

labels:
  ...
  - "traefik.http.middlewares.ignition-replacepathmain.replacepathregex.regex=^/main/StatusPing$$"
  - "traefik.http.middlewares.ignition-replacepathmain.replacepathregex.replacement=/StatusPing"
  - "traefik.http.routers.ignition.middlewares=ignition-replacepathmain"

Having the reverse proxy perform the substitution instead of the gateway seems to do the trick, just like described above. Thank you both once again!

4 Likes
#9

I ran into this same issue. Using the same approach as @accyroy in Nginx worked but this seems like something that should be addressed in the Ignition Gateway.

For reference, adding this line to the location section of the Nginx configuration works:

   rewrite ^/main/StatusPing$ /StatusPing;
2 Likes
#10

This helped, and we can log into the designer and open a project with this config. However, opening any perspective view or page doesn’t work. We only get a mysterious “no-project” text in the central view.

This doesn’t happen if we access ignition via the direct :8043 and :8088 ports. Obviously, we don’t want to keep these ports open so we’re looking at solving the nginx config.

Any ideas?

Edit
I’ve noticed in the Diagnostics window (under Help) of the Designer that it’s trying to reference the server with a -1 port number. i.e. https://<gateway>:-1

Clicking on this link just opens a browser but doesn’t navigate to the gateway.

When accessing the Designer through port 8043, that same link is https://<gateway>:8043 and when clicked navigates to the gateway page.

I’m not sure what this means, but it looks like a problem in the right direction.

#11

Designer Launcher in 8.1.6 now uses /StatusPing directly, so you will no longer need the explicit rewrite. Thankfully, you can also use the new launcher for older gateways that you’ve not yet upgraded since the issue was resolved in the launcher itself.

2 Likes
IdP redirect URI and reverse proxy with SSL offloading