This would help JAX-WS users too...
Sergey
On 11/08/14 14:10, Sergey Beryozkin wrote:
Hi,
I've updated CXF HTTP transport code to optionally react to
X-Forwarded-Proto and X-Forwarded-For headers, IMHO it makes sense to
'help' a bit at the transport level for users to avoid messing with
these headers if they do not want to...
Set a new "use-x-forwarded-headers" servlet parameter to "true". This is
for 3.0.2 and 3.1.0 only...
Thanks, Sergey
On 08/08/14 09:04, Sergey Beryozkin wrote:
Sure, I think CXF can ship such a filter itself. I'm not 100% sure it
has to be done by default in CXF HTTP Transport - but we can discuss
that...
Cheers, Sergey
On 08/08/14 01:17, Matt Helgren wrote:
The use case is that we have an F5 load balancer that also offloads
all SSL processing. Requests come into the load balancer either with
SSL or without meaning http or https urls. When they are proxied to
the app server (tomcat) all knowledge of whether the request came in
through http or https is lost (all content is decrypted and sent to
port 80). We have to be able to generate pages with embedded urls
back to the app or redirects with the scheme that was used for the
incoming request. Worst case all the requests are coming in via SSL
(https urls) but we are building and returning urls that are http and
the user-agent is then accessing subsequent urls without encryption
(which they complain about if the containing page was served via ssl).
As I understand it these headers are defacto standards that were
devised to help software solve this problem. See
http://en.wikipedia.org/wiki/List_of_HTTP_header_fields and the entry
for X-FORWARDED-PROTO. Some of the java technologies in our stack
does understand these headers and produces generated urls with the
appropriate scheme.
It would be great if this were introduced in the future with a
contextual property or such. In the mean time it sounds like I will
have to adjust the scheme on URLs myself. I'll take a look at the
ContainerRequestFilter you mention.
Thanks.
Matt
On Aug 7, 2014, at 3:03 PM, Sergey Beryozkin <[email protected]>
wrote:
Hi
There's no requirement for UriBuilder to detect X-FORWARDED_PROTO.
What code sequences you have in mind, is it something like:
return Response.seeOther("relative/path"),
and the returned Location headers would have an absolute URi with the
scheme taken from X-FORWARDED_PROTO ?
Or say
UriBuilder ub = UriInfo.getRequestUriBuilder();
and again, even though the actual URI is say "http://..."; we;d have
UriBuilder initialized with the X-FORWARDED_PROTO value ?
Or something else ?
I'm afraid initially you'd have to deal with it yourself, may be the
good approach is to modify the request URI in PreMatching
ContainerRequestFilter if this header is available.
At the next stage we might consider introducing a contextual property
which will get the runtime to check the header...
Cheers, Sergey
On 07/08/14 18:44, Matt Helgren wrote:
Not looking for it to set the header, just consume it from the http
request and use it in the UriBuilder. It dont think OAuth2 is
doing anything wrong. If anything its the UriBuilder should be
checking if the X-FORWARDED-PROTO header came in on the request and
using that to determine the scheme for the uri built.
For example our load balancer adds the header X-FORWARDED_PROTO
header with value "https" then the uri builder should build the
returned URI with scheme = "https".
I'm looking at the code in org.apache.cxf.jaxrs.impl.UriBuilderImpl
and it looks like it does build the url string with whatever scheme
has been set on the object. Not clear on what or where something
sets the scheme on the object or if URIBuilderImpl should
autodectect the scheme if its not told about any scheme (ie should
it be looking for the header).
Thanks for any help. Really rather not start modifying the url
strings in my code based on the presence of the header but that is
my last resort.
Matt
On Aug 7, 2014, at 9:34 AM, Sergey Beryozkin <[email protected]>
wrote:
Hi Matt
On 07/08/14 17:19, Matt Helgren wrote:
Hi All,
We have implemented OAuth2 from CXF in our application. More
recently we are using a load balancer for our application and the
application does not have direct knowledge of the scheme (http or
https) used for requests. I downloaded the source and looked for
any mention of X-FORWARDED-PROTO but did not see one. So my
question would be is there or will there be any support for the
X-FORWARDED-PROTO for uri building? Thanks much.
In what part of the overall OAuth2 application you'd expect this
header be set ? Would you like to have it set when a 3rd party
client redirects the user to authorize ?
Cheers, Sergey
Matt
