Hi,
Am 24.05.2022 um 19:09 schrieb Shawn Heisey:
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.
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)
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.
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
uschind...@apache.org
ASF Member, Member of PMC and Committer of Apache Lucene and Apache Solr
Bremen, Germany
https://lucene.apache.org/
https://solr.apache.org/
_______________________________________________
jetty-users mailing list
jetty-users@eclipse.org
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jetty-users
