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
