Issues with proxy and internal networking as containers start up

[carlsonp]

I have what I think could be an opportunity to adjust how the hostnames are created and referenced within ShinyProxy.

We have a company proxy server that requires all outbound network traffic to the wider internet go through the proxy. We also have an external identity provider using OpenID Connect. I've been working to swap our authentication and access over to this new identity provider. I have modified the Docker image and added environment variables as usual for HTTP_PROXY, HTTPS_PROXY, and NO_PROXY. However, I found out that I had to also add them to the startup of ShinyProxy as they didn't seem to be picked up. I added the following:

CMD java -jar \
    -Dhttp.proxyHost=ourproxy.company.com -Dhttp.proxyPort=80 \
    -Dhttps.proxyHost=ourproxy.company.com -Dhttps.proxyPort=80 -Dhttps.proxySet=true \
    -Dhttp.proxySet=true \
    -Dhttp.nonProxyHosts='localhost|localnets|ourcompany.com|127.0.0.1' \
    /opt/shinyproxy/shinyproxy.jar

With this set, I was able to get OpenID Connect and Single-Sign-On (SSO) working.

However, I noticed that I was unable to get Shiny applications to properly start up. I get a message "Failed to start app..." in the UI. However, when I look at docker ps, I see the container start up just fine.

What I suspect is the hostnames for the containers are being incorrectly routed to our company proxy. I don't want the networking to the containers routing through the proxy but I also need some way of referencing them. Instead of the hostname for the container that gets spun up being called: 9f576925a7f8, maybe it should be given some kind of common ending like: 9f576925a7f8.local?

This way I could add *.local to NO_PROXY. Without this, I'm not sure how I can configure both SSO and get ShinyProxy working properly.

When I turn up logging I see messages like this:

2024-12-16T22:41:59.080Z DEBUG 7 --- [ProxyService-16] s.n.www.protocol.http.HttpURLConnection  : sun.net.www.MessageHeader@2fd0c3bf5 pairs: {null: HTTP/1.0 404 Not Found}{Content-Type: text/plain; charset=UTF8}{Server: BigIP}{Connection: close}{Content-Length: 66}
2024-12-16T22:41:59.482Z DEBUG 7 --- [ProxyService-16] s.n.www.protocol.http.HttpURLConnection  : sun.net.www.MessageHeader@541028535 pairs: {GET http://9f576925a7f8:3838/ HTTP/1.1: null}{User-Agent: Java/17.0.11}{Host: 9f576925a7f8:3838}{Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2}{Proxy-Connection: keep-alive}

This again makes me suspect networking issues between ShinyProxy and the containers it is starting up.

We have a production server with the exact same setup but a different internal identity provider and that doesn't have the override for the CMD startup and that has no issues.

Does anyone have any further ideas or thoughts? Thanks.

ShinyProxy version: 3.1.1

[billy34]

You can control the naming of the spun container by defining resource-name attribute in the app spec definition.
It uses SpEL expressions.
Here for example I build the container name from it's app id and the first 8 digits of the container id.
resource-name: "#{proxySpec.id}-#{proxy.id.substring(0,8)}"

Maybe look at this to append .local to the default naming (sp-container-#{proxy.id}-0)
resource-name: "sp-container-#{proxy.id}-0.local"

[carlsonp]

I tried your suggestion but sadly, it didn't seem to work. The HttpConnection is still using just the ID when it makes the HTTP GET check.

2025-01-09T17:16:11.756Z DEBUG 7 --- [ProxyService-16] s.n.www.protocol.http.HttpURLConnection  : sun.net.www.MessageHeader@4e1df9c85 pairs: {GET http://8cc17fef08f0:3838/ HTTP/1.1: null}{User-Agent: Java/17.0.11}{Host: 8cc17fef08f0:3838}{Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2}{Proxy-Connection: keep-alive}

Perhaps whatever is being passed into getTargets should be adjusted or add the resource name value in addition to the container ID to check?

I can see the changes I made using the new resource-name in the name of the container that it tries to start up.

I also tested running a ping command from within ShinyProxy. I can see the container try to start up and I can also successfully ping the container before it gets killed off during the startup process. This to me shows I have the no-proxy settings correct as it doesn't appear to be a networking issue between the containers.