Mailing-List: contact users-help@wicket.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@wicket.apache.org
MIME-Version: 1.0
In-Reply-To: 
 <CADop=6fNsf-A1mb9U4_He_cDQXDdZaEG62woy+t5J4J7hXjXcQ@mail.gmail.com>
References: 
 <CADop=6fNsf-A1mb9U4_He_cDQXDdZaEG62woy+t5J4J7hXjXcQ@mail.gmail.com>
From: Martin Grigorov <mgrigorov@apache.org>
Date: Thu, 12 Dec 2013 10:00:17 +0200
Message-ID: 
 <CAMomwMoGhbGvvtWbvW0z4A0AjxSVAoi=jp1bd4Uhe-TG4CODzQ@mail.gmail.com>
Subject: Re: SSL Offloading and Wicket
To: "users@wicket.apache.org" <users@wicket.apache.org>
Content-Type: multipart/alternative; boundary=001a11c37d28de965404ed51be05

--001a11c37d28de965404ed51be05
Content-Type: text/plain; charset=UTF-8

Hi,

I think you should ask in Tomcat mailing lists.
The related code in Wicket is:
https://github.com/apache/wicket/blob/master/wicket-core/src/main/java/org/apache/wicket/protocol/http/servlet/ServletWebResponse.java?source=cc#L232

As you can see Wicket always passes relative url to the underlying
container.
The container makes it absolute, i.e. sets the scheme, host, port and full
path, and then sets the "Location" response header.


On Thu, Dec 12, 2013 at 6:05 AM, Matthew Welch <matthew@welchkin.net> wrote:

> 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
>

--001a11c37d28de965404ed51be05--