Closed andytson closed 2 years ago
I assume this is also an issue by the looks of things for the allowed routes functionality as well, as it seems to refer only to the own request as well.
The TrustedIps I've not had this problem with
I'm wondering about the implementation for the fix.
Though I could just do a check for X-Fowarded-Method and use if there only if reverse-proxy mode.
Just to update, ingress-nginx k8s controller sets up X-Original-Method instead of X-Fowarded-Method. It seems dangerous to choose one or the other without knowledge of which is correct, if a client can fake the other header and bypass on other methods
It seems dangerous to choose one or the other without knowledge of which is correct, if a client can fake the other header and bypass on other methods
In general, we have left the reverse-proxy
as a more insecure option where we recommend that users filter out headers before making the subrequest (Nginx may already do some of this by default), so I think working on both could be allowed based on the reverse-proxy
flag, but the alternative is to have configuration for this to allow users to choose which value to use
I'm currently solving this issue targeting the specific ingress that needs preflight in k8s with ingress-nginx via:
metadata:
annotations:
nginx.ingress.kubernetes.io/auth-snippet: |
if ($request_method = OPTIONS) {
return 200;
}
This issue has been inactive for 60 days. If the issue is still relevant please comment to re-activate the issue. If no action is taken within 7 days, the issue will be marked closed.
I can confirm this behavior is still present in v7.4.0.
At the present time, the traefik way to handle it is to create two rules:
# Expose API for preflight requests
- kind: Rule
match: Host(`api.tralala.com`) && Method(`OPTIONS`)
priority: 200
services:
- name: tralala-svc
port: 5000
# Expose API with authentication
- kind: Rule
match: Host(`api.tralala.com`)
priority: 100
middlewares:
- name: api-oauth2-proxy # middleware ForwardAuth
services:
- name: tralala-svc
port: 5000
Expected Behavior
When using skip-auth-preflight with oauth2-proxy behind Nginx or Traefik and auth_request/forwardAuth sub-requests are used, OPTIONS requests to the ingress should be allowed
Current Behavior
It's blocked because the check in oauth2-proxy just checks it's own request (which is a sub-request) method
Possible Solution
oauth2-proxy should use X-Original-Method/X-Forwarded-Method for the preflight check when in reverse proxy mode.
Steps to Reproduce (for bugs)
Context
This prevents the OPTIONS request succeeding, which doesn't receive cookie credentials.
Your Environment