search cancel

Access to Google site failed due to client's authorization header


Article ID: 168606


Updated On:


ProxySG Software - SGOS


The request to one of the Google sites has an authorization header before being challenged by the proxy's authentication policy. The request header looks like the one below:

Connection: keep-alive
Content-Length: 35
> Authorization: Bearer ya29.IQB2fJ5dROAGhB8AAADUTd9BtBgvX9XGzWHNj1sK77wOKVnSGaskJfFRKYESuA
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.114 Safari/537.36
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Cookie: <snipped>



The HTTP proxy sees that the user has been authenticated, but isn't sure whether the credentials should be forwarded—it doesn't know whether the ProxySG consumed them on this transaction or perhaps on an earlier transaction. It then chooses not to forward them to avoid leaking them to a third-party origin content server.



If the server were using basic credentials, you could forward them using the server.authenticate.basic gesture. However, that's not an option in this case since the client is presenting "Bearer" credentials.

The CPL policy "authenticate(no, upstream_authentication)" could be used in this case in order for the proxy to forward the client's credentials.