[BUG] Login window does not use the port that was configured in launcher window

[mfg92]

Describe the bug
We use NextGen Connect on a custom port 28443. This port is configured in the Administartor launcher, as you can see here:

After clicking on "launch" the login window appears, but here the wrong port is used, as you can see here:

To Reproduce
Setup steps (if required). Example:

1. Have NextGen Connect server running o non-default port like 28443

Steps to reproduce the behavior:

1. Create a new Connection in the Administartor launcher with the correct URL and port
2. Click on 'Launch'
3. Wait for the login window
4. Notice the wrong port is used

Expected behavior
The port specified in the launcher should be used in the login window.

Actual behavior
The default port auf NextGen Connect is used.

Environment (please complete the following information):

• Windows 10 (on client side)
• Java Distribution/Version Oracel Java 8 (on client side)
• Connect Version 3.11
• Connect is running in Docker

[jonbartels]

I think you can set the server.url property in mirth.properties to address this.

I think post 37 and 38 in this thread describe the same issue - https://forums.mirthproject.io/forum/mirth-connect/general-discussion/17834-administrator-launcher-1-1-0-released/page3#post101995

You can see how its used in the code at

connect/server/src/com/mirth/connect/server/servlets/WebStartServlet.java

Line 189 in 924d186

if (StringUtils.isNotBlank(mirthProperties.getString("server.url"))) {

This feature is actually kind of a cool piece of MC history - its the sixth issue from the old JIRA #30

This may not entirely solve the stated problem in that the server.url is set per MC server. It's possible for multiple launcher instances to use different URLs or ports to access the same MC instance. Does this condition apply to your issue @mfg92 ? VPNs or port tunneling or containers-on-different-ports would change the URL on a case-by-case basis.

If that does apply - then the Launcher would need to be updated to alter the JNLP with a URL.

[pacmano1]

I agree with this bug - due to port tunneling, NAT, etc. that may change the port as seen by the admin client and noted by @jonbartels

[pladesma]

It sounds like Jon's suggestion of using server.url should address the issue. Is there some specific use case that would require different behavior?

[pacmano1]

@jonbartels 's suggestion works if all clients use the same port, That isn't a great assumption. In the office I might use 8443, over ssh I might port forward 18433 (since I have mirth installed locally).

Re-read his second to last paragraph again in post #4655 (comment)

Overriding the port on login is trivial of course, however it would be nice for it to persist.

[mfg92]

I solved the problem for me by setting the environment variable _MP_HTTPS_PORT=28443 in the docker-compose.yaml (which has the same effect as setting https.port in mirth.properties). That way I did not need a port mapping from 8443 to 28443 in docker any more.
Because of this mirth is actually running on the port mirth is thinking it is running on. Now the login window uses the right port.

But as @jonbartels mentioned there are cases were one accesses mirth using port forwarding etc. and for suche cases it would be nice to have the launcher UI and the login UI show the same port. Are there any use cases were you do not want to have the same port in both UIs?

[jonbartels]

Are there any use cases were you do not want to have the same port in both UIs?

Maybe. @mfg92 presented a very simple use case that is easy to fix. I am trying to think if the different URL patterns tolerated by the Launcher make it harder to solve the presented problem without breaking other use cases.

The Launcher tolerates several URL formats:

• http:https://localhost:8080/
• http:https://localhost:8443/
• http:https://localhost:8080/webstart.jnlp

The Launcher then uses those URLs to acquire the webstart.jnlp. The JNLP then has URLs referencing the secure port (typically 8443).

For use cases with only different defaults - changing MC settings works. MC knows what it's ports are. The launcher should just get the info it needs from MC and not require any substitution.

For use cases where tunnels or VPNs or containers change ports the Launcher would be sensitive to what URL the user put into the Launcher. The secure port would typically be used in the Launcher and whatever tunnel/vpn/container setup exists because its the one that matters. Setting up a tunnel for both 8080 and 8443 is a waste of time because 8080 is only used to retrieve the JNLP.

Is there a consistent computation that the Launcher could use to get the JNLP then determine if the JNLP has a URL port/hostname/pattern that is correct?

What if the Launcher got the JNLP then probed the given port and if the given port did not connect the Launcher prompts to fix it before invoking the Client and changing Client arguments as necessary?

I worry that I am overthinking the problem.

[ChristopherSchultz]

Mirth Connect Administrator should use the exact same URL that MCAL used to launch it. The server shouldn't be providing the URL back to the client... the client already knows what the URL should be, because the client provided it in the first place. If it doesn't have such a thing already, MCA needs some kind of command-line option to override the connection URL and MCAL can just set that.