fix(chore): upd deprecated chi RealIP middelware

[maki5]

replaced deprecated chi RealIP middleware with ClientIPFromRemoteAddr and ClientIPFromXFF as a fallback option for proxy

closes ##3082

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

🟢 Metrics 15 complexity

Metric	Results
Complexity	15

View in Codacy

🟢 Coverage 36.36% diff coverage · 0.00% coverage variation

Metric	Results
Coverage variation	✅ 0.00% coverage variation (-1.00%)
Diff coverage	✅ 36.36% diff coverage

View coverage diff in Codacy

Coverage variation details

	Coverable lines	Covered lines	Coverage
Common ancestor commit (2ce9fae)	88320	20759	23.50%
Head commit (e2f4e7e)	88350 (+30)	20765 (+6)	23.50% (0.00%)

Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch: <coverage of head commit> - <coverage of common ancestor commit>

Diff coverage details

	Coverable lines	Covered lines	Diff coverage
Pull request (#3464)	44	16	36.36%

Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: <covered lines added or modified>/<coverable lines added or modified> * 100%

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}

[rhafer]

Hm, reading through https://github.com/go-chi/chi/blob/master/README.md#choosing-a-clientip-middleware, go-chi/chi#708 and other issues linked from there, this one is a becoming a bit of a can of worms.

Apparently there is no real one-size-fits-all replacement for the RealIP middleware, depending on the concrete setup different middlewares from the ClientIPFrom... family have to be used and additional configuration would be needed.

For our proxy services:

• When the proxy is directly exposed the ClientIPFromRemoteAddr could be used
• It the used reverse proxy unconditionally set and overwrites a specific header with the client IP it would be ClientIPFromHeader
• If the IPs of all involved reverseproxys are know ClientIPFromXFF
• If the number of trusted reverseproxy hops between the client and our proxy service is know ClientIPFromXFFTrustedProxies

For all other services that used the RealIP middleware it would be good if our proxy service unconditionally adds and overwrites a header with the value resulting from the above ClientIPFrom... middlewares. The "underlying" services could then just use ClientIPFromHeader

And even with the above there will be case where we would not be able to determine the correct remote IP address.

[rhafer]

According to the docs (https://github.com/go-chi/chi/blob/master/README.md#choosing-a-clientip-middleware) only one middleware from the ClientIPFrom.... should be selected. Which one depends on infrastructure.

As we allow to deploy in many different ways I don't think there is a single choice that works for us in allow possible configurations. 😢

[maki5]

@rhafer if I got it correctly we need an additional config where the ip "extraction" strategy will be specified, based on the value from config we apply the correct chi middleware and through it extract the real ip address. Did I got it right?

[rhafer]

@rhafer if I got it correctly we need an additional config where the ip "extraction" strategy will be specified, based on the value from config we apply the correct chi middleware and through it extract the real ip address. Did I got it right?

Yes, exactly. I wonder however what a good config would look like that fits the above suggesting without getting to complicated.

Any suggestions?

@micbar @butonic maybe you want to chime in here as well as you have more insights into possible setups, especially when it comes to k8s setups (where multiple reverse proxys a probably not an exception)