Hi,
I've never run it in such a scenario, but I believe it's possible.
After the UI client loads, it tries to determine the location of the API backend, which may or may not be deployed on the same host and port as the UI. To do so, it applies the following strategy.
First, it tries to query a little service, which has to be deployed alongside the UI client, at path /portofino. This service will compute and return the backend URI as described later.
If the service is not available, the client will fall back to a default URL,
http://localhost:8080/. However, the developer of the application can override this fallback URL when instantiating the
portofino-app component:
apiRoot should be really called fallbackApiRoot here; as it is, it's a bit misleading, because as we've seen the API URL will only be in effect if the support service is not available.
If you've created your application from the Maven war archetype, or downloaded the pre-built application from SourceForge (which is built starting from the same archetype), then the little UI support service is already bundled with the application and available without any intervention by the developer. So, let's focus on this scenario and see how the service determines the URL of the APIs.
The starting point is the portofino.api.root parameter in the web application descriptor (i.e. web.xml file). This can be:
- A path such as api or /api. In this case, the backend is assumed to be on the same server (host and port) as the UI. Due to the way servlet containers work (i.e. Tomcat here), in case the application is deployed behind a correctly configured reverse proxy, the host and port will be automatically adjusted to match those of the proxy, and everything will work out of the box.
- An absolute URL such as https://some.other.host:1234/my-app/apis. In that case, the URL is used as-is.
In your setup, a port-forwarding router is not the same as a reverse proxy, because it doesn't inform the HTTP server down the line of its presence – port forwarding happens at a lower level and is not specific to HTTP. Therefore, Tomcat is unaware that the request was actually made to a different port, and will think that its local port is the one that's to be used to contact it from the outside, which is not the case.
So, I think that if you set portofino.api.root to a full URL (such as, assuming the router is forwarding port 80 to port 8080 where Tomcat is running, http://<your host>:80/api), the client should be able to contact the server and you should be allowed to log into the application.
Cheers,
Alessio