| Re: [jetty-users] Solr admin UI redirecting root path requests to http instead of https |
Hi,
On 5/24/22 10:31, Shawn Heisey wrote:
Where would I do HttpConfiguration.setRelativeRedirectAllowed(true)? That looks like Java code, and Jetty is not embedded. This is the jetty.xml in Solr 8.x:
https://gitbox.apache.org/repos/asf?p=lucene-solr.git;a=blob_plain;f=solr/server/etc/jetty.xml;h=e2f4ab095984aac27185a9879964862f9ba35d4d;hb=refs/heads/branch_8_11
If we incorporated the ForwardedRequestCustomizer that Uwe mentioned in our jetty config, would that work for those using a proxy as well as those NOT using a proxy? I see that this config is already in our jetty.xml, commented.
What I am hoping for is coming up with an xml config that allows this to work properly for all users whether they incorporate a proxy or not. Most proxies send X-Forwarded-For, and configuring X-Forwarded-Proto is typically very easy.
It has no side effects, but it may open some security issues:
Normally, a reverse proxy would be the only one setting the
request headers (also for example the remote user's IP, not only
scheme and other metadata). The reverse proxy would also strip any
X-Forwarded or Forwarded headers from the client and only add its
own ones.
If you do not have a reverse proxy, the client could send the
headers and cause incorrect access log entries by faking IP
addresses or causing invalid redirects. The first may be a
security issue, especially if you have ip-based access control.
The latter is not so serious.
I uncommented the call to ForwardedRequestCustomizer and configured haproxy to send the X-Forwarded-Proto header. This fixed the redirect, and it looks like a request sent directly to Solr still works properly too. Can anyone imagine any unintended side effects from uncommenting ForwardedRequestCustomizer in our source repo's XML configs for jetty?
No side effects, it is only a security issue (see above). I wold
make it a boolean option in Solr's config.
Is there a more generic fix that would cause jetty to NOT send an absolute URL path in its redirect? (what I was initially aiming for)
According to "original" HTTP standards, the URIs has to be
absolute, but it still worked with most browsers also in the past.
Since 2014 this is standardized and it should now work relative (<https://www.rfc-editor.org/rfc/rfc7231#section-7.1.2>).
So in general nowadays relative URIs should be ok, but still old
non-browser software may fail.
That depends on your reverse proxy software. At moment most of them just implement the old-style X-Forwarded- stuff. But I agree with you.If you are going to use the ForwardedRequestCustomizer do yourself a favor and only use the RFC 7239 mode.
Do not use the X-Forwarded-* headers, they are a giant mess of conflicting behaviors and rules with no standardization behind them.Big players interpret the headers differently (Google, vs AWS, vs Azure, vs haproxy, etc)
The RequestCustomizer should handle all of them. I was just
talking about them, because with Apache and NGINX you always get
those automatically.
Uwe
-- Uwe Schindler uschindler@xxxxxxxxxx ASF Member, Member of PMC and Committer of Apache Lucene and Apache Solr Bremen, Germany https://lucene.apache.org/ https://solr.apache.org/