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.
Matt On Thu, Dec 12, 2013 at 4:35 AM, Michael Haitz <[email protected]>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 <[email protected]>: > > > 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 > HTTP > > 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: [email protected] > For additional commands, e-mail: [email protected] > >
