search

ory / integrations

Apache License 2.0
19 stars 24 forks source link

fix: allow to forward custom headers #38

Closed fbnfgc closed 2 years ago

fbnfgc commented 2 years ago

Hi,

Thanks for your work on this project.

We are facing an issue with the current implementation because we would like to forward some custom headers but the list is hard-coded.

This is a proposal that won't introduce breaking changes. What do you think about it?

I've extracted the function to be able to unit test it. Does it sound reasonable to you?

Thanks!

CLAassistant commented 2 years ago

CLA assistant check
All committers have signed the CLA.

aeneasr commented 2 years ago

Thank you! From a code-perspective, this PR looks really good :) What is the use case you are trying to solve with this? Since neither Ory Self-Hosted nor Ory Cloud use custom headers I'm not sure if it makes sense to include this in the library as it makes configuration more difficult.

fbnfgc commented 2 years ago

Hi @aeneasr and thanks for your response. We are using a proxy in front of Kratos which allows us to not expose the Kratos administration APIs to end-users. This proxy is in charge of performing a fingerprint of the clients. We'd like to use some additional headers, for e.g the X-Forwarded-For header to access the user's IP address.

Our frontend is hosted on a custom domain: https://frontend.example.net/ and it uses ory/integrations to perform Kratos authentication flows. We set ORY_KRATOS_URL to https://kratos-proxy.example.net/ which forwards requests to our self-hosted Kratos at https://kratos.example.net/.

The HTTP call made to https://kratos-proxy.example.net/ is triggered by ory/integrations code which strips out our custom HTTP headers.

Here is the PR that introduced the filtering https://github.com/ory/integrations/pull/17/files.

fbnfgc commented 2 years ago

Hello @aeneasr, what do you think of this proposal? It would be an optional opt-in and shouldn't impact current or future integrations. :relaxed: