Request 'X-Authorization' as allowed header in a CORS preflight check

[rhuss]

In order to be able to use the new header X-Authorization header in a CORS request it must be white listed by a preflight CORS request as described here. I wonder, why Authorization works because this is also not a simple header and hence must be white listed, too.

@cmoulliard ran into this issue first:

[gashcrumb]

Ah, this also requires the responding entity to reply back to the preflight request with Access-Control-Allow-Headers set to the same headers also to work -> http://stackoverflow.com/questions/8685678/cors-how-do-preflight-an-httprequest, wonder that might get broken by the proxy as well... <sigh>

[rhuss]

Jolokia is very liberal ;-) and always returns all requested headers but you are right, might be that the proxy is filtering this, too. I will check that ...

[rhuss]

An option would be to put it into a 'simple header' but that definitely would be a dirty, dirty hack.

[gashcrumb]

Yeah, wonder, maybe we can just get the proxy to not overwrite that, as that probably can break other apps too.

[rhuss]

Well, we are probably doomed ;-(

'will now check, to which header the proxy itself sends back on a preflight check ...

[gashcrumb]

>ack<

[rhuss]

AFAIK the proxy is meant to filter all backend CORS headers ;-(

[rhuss]

@dhirajsb we have a serious issue now, because the proxy filters the CORS respond for allowed headers (in fact it probably even answers the CORS preflight check on its own). That means we can't use a custom header to transport the toke across the proxy and unforturnately there is currently no good solution.

I suggest we continue the discussion over within the original issue openshift/origin#4497

[rhuss]

The proxy answers to the preflight check itself and returns the following allowed headers:

Content-Type
Content-Length
Accept-Encoding
X-CSRF-Token
Authorization
X-Requested-With
If-Modified-Since

(where Content-Type wouldn't be needed because its a simple header)

[rhuss]

As mentioned on IRC the current trust relation between hawt.io and Jolokia is very weak and is only based on the availability of a certain port (8778). So even the solution with passing the token is not really secure. The only secure way would be the passing of a token from proxy to Jolokia which can be verified without a querying without a central service (i.e. with a signature a la json web token, the public key could be injected to every pod by OpenShift).

[davsclaus]

Is there more work to this ticket or can it be closed?

[abkieling]

Is there any work left in this ticket?

[gashcrumb]

Actually no, we decided to ditch this approach, so let's go ahead and close it.