Thank you again, Ben.
To get my dev environment working with nginx terminating HTTPS in front of
Jetty, the key things I had to change were:
1. In the nginx config add these lines, as you did below:
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
2. In my RunJetty main, set up the HTTP connector like this:
HttpConfiguration httpConfig = new HttpConfiguration();
// Add support for X-Forwarded headers
httpConfig.addCustomizer(new
org.eclipse.jetty.server.ForwardedRequestCustomizer());
HttpConnectionFactory connectionFactory = new
HttpConnectionFactory(httpConfig);
ServerConnector httpConnector = new
ServerConnector(server, connectionFactory);
httpConnector.setPort(Integer.getInteger("jetty.port",
8080));
connectors.add(httpConnector);
Success! Cheers!
> On 19 Dec 2021, at 7:20 pm, Ben Weidig <[email protected]> wrote:
>
> We use Jetty, too, either behind HAProxy (production) or Nginx (dev).
>
> This is my local dev nginx setup, with the domain mapped to 127.0.0.1 via
> /etc/hosts
>
> map $http_x_forwarded_proto $xscheme {
> default $scheme;
> https https;
> }
>
> set_real_ip_from 127.0.0.1;
> real_ip_header X-Forwarded-For;
> real_ip_recursive on;
>
> server {
> listen 80;
> server_name my.awesome-domain.com;
>
> return 301 https://$host$request_uri;
> }
>
> server {
> listen 443 ssl;
> server_name my.awesome-domain.com;
>
> ssl_certificate /Users/ben/.ssl/fullchain.pem;
> ssl_certificate_key /Users/ben/.ssl/privkey.pem;
>
> location / {
> proxy_pass http://127.0.0.1:8080;
> proxy_set_header Host $host;
> proxy_set_header X-Real-IP $remote_addr;
> proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
> proxy_set_header X-Forwarded-Proto $scheme;
> proxy_read_timeout 1h;
> }
> }
>
>
>
> On Sun, Dec 19, 2021 at 12:09 PM JumpStart <
> [email protected]> wrote:
>
>> Thank you Ben, you are absolutely right.
>>
>> In production, our AWS ALB (application load balancer) terminates HTTPS
>> but automatically adds the X-Forwarded-Proto header, which forwards “https”
>> or whatever the protocol was, and Wildfly respects it if you make the
>> configuration changes described here:
>> https://wjw465150.gitbooks.io/keycloak-documentation/content/server_installation/topics/clustering/load-balancer.html
>> . Redirects of relative URLs now get turned into absolute URLs with “https”
>> as the protocol.
>>
>> For my dev environment I use Jetty, often behind nginx with nginx
>> terminating HTTPS. I’ll pass on the solution for that when I find one.
>>
>>> On 19 Dec 2021, at 4:35 pm, Ben Weidig <[email protected]> wrote:
>>>
>>> Hi Geoff,
>>>
>>> I can't reproduce the behavior in our setup, redirecting with relative
>> URLs
>>> while HTTPS works fine.
>>>
>>> Which Servlet Container are you using?
>>> AFAIK it's the responsibility of the container to do the right thing and
>>> how to handle relative URLs from sendRedirect.
>>>
>>> What's in the "Location" header of the response?
>>> Still a relative URL, or already the HTTP version?
>>>
>>> Cheers,
>>> Ben
>>>
>>>
>>> On Sun, Dec 19, 2021 at 5:59 AM JumpStart <
>>> [email protected]> wrote:
>>>
>>>> I forgot to mention that HTTPS terminates at the load balancer. The app
>>>> server sees just AJP or HTTP.
>>>>
>>>>> On 19 Dec 2021, at 12:10 pm, JumpStart <
>>>> [email protected]> wrote:
>>>>>
>>>>> Hi all,
>>>>>
>>>>> At long last I’ve moved redirection of HTTP to HTTPS from the app to
>> the
>>>> infrastructure, and set tapestry.secure-enabled <
>>>> https://tapestry.apache.org/configuration.html>=false as recommended in
>>>> https://tapestry.apache.org/https.html <
>>>> https://tapestry.apache.org/https.html> . But now I’m hitting an
>> age-old
>>>> issue: page links are returning absolute URIs with “http” protocol. For
>>>> example:
>>>>>
>>>>> Link pageDeniedLink =
>>>> pageRenderLinkSource.createPageRenderLinkWithContext(PageDenied.class,
>>>>> parameters.getLogicalPageName());
>>>>> response.sendRedirect(pageDeniedLink);
>>>>> break;
>>>>>
>>>>> pageDeniedLink is a relative address, but it seems to be converted to
>> an
>>>> absolute address with “http://“ by the time it gets back to the
>> browser.
>>>>>
>>>>> This appears to have been an issue for a long time, but must have been
>>>> solved, so is there a config change I need to make?
>>>>>
>>>>> From
>>>>
>> https://users.tapestry.apache.narkive.com/dapo2zzk/url-writing-problem-with-production-mode-true
>>>> <
>>>>
>> https://users.tapestry.apache.narkive.com/dapo2zzk/url-writing-problem-with-production-mode-true
>>>
>>>> :
>>>>>
>>>>> "To be clear, it's not an HTTP/HTTPS problem I encountered, it was a
>>>>> relative/absolute URL problem. With it off, the URLs were relative and
>>>>> happy under HTTPS, with it on, the URLs were then set to absolute and
>>>>> used HTTP.”
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Geoff
>>>>
>>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>>
