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 <
geoff.callender.jumpst...@gmail.com> 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 <b...@netzgut.net> 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 <
> > geoff.callender.jumpst...@gmail.com> 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 <
> >> geoff.callender.jumpst...@gmail.com> 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: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>
