-
-
Notifications
You must be signed in to change notification settings - Fork 359
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
refactor: refactor decisions API and add traefik (#486) #487
Conversation
Refactors the decisions API location from `/decisions` to `/decisions/traefik`. Additionally, an endpoint `/decisions/traefik` has been added for integration with the Traefik proxy. Closes #263 BREAKING CHANGE: Please update `/decisions` to `/decisions/generic` in all applications that use the ORY Oathkeeper Decisions API. Co-authored-by: Michiel Vanderlee <[email protected]>
Any new here? |
Hi, @aeneasr, I hope you are well! We are faced with the problem of matching Host from the incoming requests, which is why we would like to use a new endpoint for traefik, to which custom headers can be passed. Thank! |
We're currently hiring developers to help with the refactoring as I don't have time to work on this - depending on that process we'll see how it goes. We probably want Oathkeeper as part of our cloud offering in 2022 so will be working on that latest then |
I'm really impressed with the software so far from Ory, and I wish I had golang code under my belt so I could offer some help here, sadly as I don't I'd like to simply offer some feedback instead, and I hope that's ok. I think that attaching this to the specific term Traefik is a bad move that will come back to bite as more and more auth services may expect specific implementations.A more generic approach would better suit the goal and I feel that config may be better suited to deal with the different patterns that the decisions api can provide. ---
serve:
api:
port: 4456
decision_strategy: path|headers
requestHeaders:
host: 'X-Forwarded-Host'
method: 'X-Forwarded-Method'
protocol: 'X-Forwarded-Proro'
uri: 'X-Forwarded-Uri' How about something along these lines? This way if a custom auth service used different headers (like one I built a while back) it could be easily plugged in to Oathkeeper. |
I currently do not have time to work on this, closing it for now. |
This is an umbrella PR for #441