Hi, In short: you need a reverse proxy.
Longer story: It is a bit blurry for me now because I did it one year ago but here is what I did for one of my applications that is deployed at Azure: 1) created 3 images (Ubuntu), named "ubuntu1", "ubuntu2", ... 2) each of them runs Tomcat (for the Wicket app) on ports 8081, 8082, 8083 respectively. Tomcat listen on somemagicurl.cloud.net 2.1) these ports are opened only in my Azure account (don't remember the exact term for my private network at Azure) 3) each image also runs Nginx at port 80, as a proxy. 3.1) each Nginx knows about the three Tomcat (for failover) 3.2) Azure load balancer balances the Nginx instances, so they serve www.myrealapp.com 3.3) Nginx config uses reverse proxy to fix the urls coming from Tomcats Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Thu, Dec 10, 2015 at 8:48 PM, Rob Audenaerde <rob.audenae...@gmail.com> wrote: > Hi all, > > I'm trying to host a Wicket Application in an Azure cloud environment. A > third party with Azure knowledge (which I lack atm) put up a proxy for us > that enforces 2factor authentication. If the user is allowed in, the > traffic is send to our application. > > That way we don't have to spend too much time internet-hardening* our > application, while still being able to run it in the cloud. > > However, it seems Wicket (/Jetty?) is redirecting to browser to absolute > urls, and these are not reachable from the browser. > > For example, our app runs at somemagicurl222343.cloud.net, and is > available > at proxy url: client-proxy.cloud.net. Redirects are given to > somemagicurl222343.cloud.net, which is not directly reachable. > > What would be the 'proper' solution? > > I think the proxy might rewrite redirects (not sure how), but maybe > relative redirects would solve the issue as well? > > > > *we stick to OWASP etc. as much as possible, but it is sensitive data so we > try to be on the safer side by keeping the application behind a fence. >
