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 >>>> >>> >> >
