Re: SSL Offloading and Wicket
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 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 : > > > 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: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
Re: SSL Offloading and Wicket
That makes sense. I'll ask there. Thank you. Matt On Thu, Dec 12, 2013 at 2:00 AM, Martin Grigorov wrote: > 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 > 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 > > >
Re: SSL Offloading and Wicket
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 : > 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: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: SSL Offloading and Wicket
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 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 >
SSL Offloading and Wicket
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
