zalando
feature: allow client redirects via 302 responses (#3130)
This commit changes the behaviour of the webhook filter when a 302 Found response is received from the AuthN/AuthZ endpoint. As a result, it allows front-end facing (i.e. non-API) traffic to be filtered via the webhook.
Documentation updates and increased test coverage are included.
Incidental: Prevent the webhook client from following redirects from the AuthN/AuthZ endpoint: during testing I realised that the default net/http behaviour was in use - i.e. redirects were followed. Is this an intended behaviour of the filter: it's not documented, and it seems potentially risky?
Please take a look at #3130 for more details.
Changes:
- Update to the documentation -
filters.md. - Update to the auth
reject()function, whereby theLocationheader is forwarded to the client if a302is encountered from the AuthN/AuthZ endpoint. - Prevent the webhook filter from following 302 redirects.
- Update tests to cover 302 redirect forwarding.
I'm more than happy to adapt or change the approach if required - especially if there's any reason why the webhook filter is expected to follow redirects itself.
Bringing the webhook filter closer to traefik's ForwardAuth functionality - i.e. having more control over the response returned to the client - would be very useful though!
Any plans to merge this change?
Can you share your use case? In my point of view it has a potential problem but also a useful change. In general who follows the redirect should not be an issue, but behavior change is always a higher risk factor.
Sorry for bumping this after such a long time. I want to use skipper for front-end traffic and use authelia for authentication. The original problem described here - https://github.com/zalando/skipper/issues/3329
There are open comments about it. Maybe you can check if you can fix it, such that it is usable to integrate with authelia webhook.