Hi Martin, Thanks for the reply, I will look into it!
-Rob Verstuurd vanaf mijn iPad > Op 10 dec. 2015 om 21:42 heeft Martin Grigorov <[email protected]> het > volgende geschreven: > > 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 <[email protected]> > 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. >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
