Open eratolekov opened 8 months ago
Same issue here with v0.40.7! Ory ppl, i am happy to send logs
@eratolekov have you been able to sort this out on your end?
@eratolekov have you been able to sort this out on your end?
nope
I am in the same boat
When taking a look in the code. It seems that the bool trust_forwarded_headers
does not tell Oathkeeper Proxy to use the x-forwarded-*
headers to match the rules. But rather tells Oathkeeper Proxy to pass some headers to the outbound request as seen here:
https://github.com/ory/oathkeeper/blob/master/proxy/proxy.go#L112
I dug some deeper and I see that the decision api uses the x
headers:
https://github.com/ory/oathkeeper/blob/master/api/decision.go#L42
But the Proxy does not: https://github.com/ory/oathkeeper/blob/master/proxy/proxy.go#L168 https://github.com/ory/oathkeeper/blob/master/proxy/proxy.go#L126
Facing the same issue when using oathkeeper with kong.
Oathkepper will not match the route properly when the incoming headers have x-forwared-*
, despite host
and path
headers being correct.
And on kong side, it is quite hard to disable x-forwarded
headers :(
Preflight checklist
Ory Network Project
No response
Describe the bug
Hi Ory Team
I guess the access rules of Ory Oathkeeper do not support X-Forwarded-* headers properly.
Reproducing the bug
Steps to reproduce a bug with x-forwarded headers
Actual result:
Expected result:
While, request with
Host
header works like a charm:Response:
Relevant log output
No response
Relevant configuration
Version
0.40.6
On which operating system are you observing this issue?
Linux
In which environment are you deploying?
Docker Compose
Additional Context
No response