We are considering something along those lines you are suggesting as an
alternative.As far as load balancers, we actually have two separate
situations: one uses AWS Elastic Load Balancer and the other HAProxy.


On Thu, Dec 12, 2013 at 4:35 AM, Michael Haitz <michael.ha...@1und1.de>wrote:

> you could use "proxyPort“ in your connector configuration, but this will
> always override ‚getServerPort‘ with this value no matter you’ve a http or
> https request.
> Do you use an apache or nginx in front?
> Am 12.12.2013 um 05:05 schrieb Matthew Welch <matt...@welchkin.net>:
> > I'm sure I'm missing something simple as there are certainly many others
> > using similar setups, but I cannot figure out what I'm doing wrong.
> >
> > We force all requests from the public internet to use HTTPS when
> accessing
> > our app.We terminate SSL at the load balancer and the request that
> actually
> > hits Apache and then Tomcat is straight HTTP. The load balancer adds the
> > proper X-Forwarded-Proto headers to the requests heading back to the app
> > server and Wicket and we've confirmed that these are being received.
> We've
> > setup the XForwardedRequestWrapperFactory in our web application init. We
> > can even confirm that request.getScheme() is properly returning "https"
> > inside our application.
> >
> > Where things break down is when Wicket issues a redirect, which of course
> > it does all of the time as people navigate from page to page. For some
> > reason, the issued redirects are always HTTP, instead of HTTPS. These
> > redirects themselves eventually get redirected back to HTTPS by our load
> > balancer on their return trip from the client, but many of our customers
> > are ultra security conscious and have firewalls in place that won't even
> > allow those initial HTTP requests through, so we've got a problem.
> >
> > We've traced through the Tomcat code and the cause is
> > in org.apache.catalina.connector.Response. This is the original response
> > that was created when the container first began processing the request.
> It
> > carries a pointer to the "original" request as well and it uses this
> > request with its getScheme(), getServerPort(), and getServerName() to
> > generate the redirect that is eventually returned. It does not use the
> > "wrapped" request that contains the values determined from processing the
> > X-Forwarded headers.
> >
> > As I said, I'm sure this is working as intended and that we've just
> missed
> > something somewhere, but for the life of me, I can figure out what it is.
> >
> > Any ideas? We need Wicket/Tomcat to produce HTTPS redirects.
> >
> > Matt
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org

Reply via email to