Add Referrer filter option

[VinayBhalerao]

3scale SAAS and on-prem product supports Referrer filter. https://support.3scale.net/docs/api-authentication/authentication-patterns. We had the option to enable referrer filter on old nginx files https://support.3scale.net/codehub/referer-filter-nginx.

With the recent development of apicast, there is a need to have this option available as an env variable.

Todo.

• While starting the gateway use env variable APICAST_REFERRER_FILTER value true|false
• When done override

https://github.com/3scale/apicast/blob/57790a667b6b6a035ce1ef6c17d3a6637095fd94/apicast/conf.d/apicast.conf#L19

with

set $path /transactions/authrep.xml?$backend_authentication_type=$backend_authentication_value&service_id=$service_id&$usage&$credentials&referrer=$http_referer$log;

• Test cases

[mikz]

I believe this is something that could be solved by a policy in the next release.

[davidor]

Adding to 3.3 milestone as agreed with @andrewdavidmackenzie

[andrewdavidmackenzie]

Is a P2 priority at the moment for 3scale/Red Hat, but seemed an easy one.

[davidor]

@mikz I'm not sure this should be implemented as a new policy. It would need to be combined with the APIcast policy anyway to work.

If I understood this correctly, we just need to optionally add a new param to the authrep call to backend. There are only 2 calls in the code to backend_client.authrep() and both of them are in proxy.lua. It should be pretty straightforward to add a new param according to a new env we set for this.

[mikz]

@davidor The only way to make this policy would be to have some generic way for policies to add params to the authrep call: https://github.com/3scale/apicast/blob/7b06e3ed8fcce3fd6aecdb41eb216ffc9f73d56e/gateway/src/apicast/proxy.lua#L139
https://github.com/3scale/apicast/blob/7b06e3ed8fcce3fd6aecdb41eb216ffc9f73d56e/gateway/src/apicast/proxy.lua#L316
https://github.com/3scale/apicast/blob/7b06e3ed8fcce3fd6aecdb41eb216ffc9f73d56e/gateway/src/apicast/proxy.lua#L330

I think we should try to make everything possible with policies even though it might be more straightforward as a flag, just because it will enable more flexibility for other customizations.

[davidor]

In my opinion, implementing a generic way to allow policies to add params to the backend calls is more valuable than having this implemented as a policy. But we need the former to achieve the latter, so ok, let's give it a go and see how it looks.