bpholt
Sep 26th, 2011, 06:41 PM
We're using OAuth 1, and I think I've found an issue with CoreOAuthProviderSupport. The getSignatureBaseString method relies first on the configured base URL, but otherwise falls back on the value of request.getRequestURL().
According to the spec (http://tools.ietf.org/html/rfc5849#section-3.4.1.2), for the purposes of request signing, "The host and port values MUST match the content of the HTTP request 'Host' header field." This header value may differ from the value returned by getRequestURI, which according to the JavaDoc, "Returns the part of this request's URL from the protocol name up to the query string in the first line of the HTTP request."
My applications are deployed behind a load balancer, so we see requests that come in by IP address. In this case, the request URI differs from the Host header and the signature value is wrong. We worked around this for a while by explicitly setting the base URL in our configuration, but we've decided this is too inflexible (since it means we can't test our servers directly). I'm thinking about extending CoreOAuthProviderSupport so that the getBaseUrl(HttpServletRequest) implementation uses the Host header if present, and falls back to the existing implementation if not.
I can file a JIRA request if anyone agrees this is a problem, and potentially contribute our fix if it works (although that would have to be coordinated through our legal department).
thanks,
Brian
According to the spec (http://tools.ietf.org/html/rfc5849#section-3.4.1.2), for the purposes of request signing, "The host and port values MUST match the content of the HTTP request 'Host' header field." This header value may differ from the value returned by getRequestURI, which according to the JavaDoc, "Returns the part of this request's URL from the protocol name up to the query string in the first line of the HTTP request."
My applications are deployed behind a load balancer, so we see requests that come in by IP address. In this case, the request URI differs from the Host header and the signature value is wrong. We worked around this for a while by explicitly setting the base URL in our configuration, but we've decided this is too inflexible (since it means we can't test our servers directly). I'm thinking about extending CoreOAuthProviderSupport so that the getBaseUrl(HttpServletRequest) implementation uses the Host header if present, and falls back to the existing implementation if not.
I can file a JIRA request if anyone agrees this is a problem, and potentially contribute our fix if it works (although that would have to be coordinated through our legal department).
thanks,
Brian