Closed CodeSteele closed 4 years ago
Yes, please
Hey @karlheyes with the closing of #286 we're eyeballing having to pull upstream again for critical functionality, this functionality is the only thing I know of that is making us rely on our fork, so before I rebase this PR/pull your upstream changes, a few questions:
1) Is this something you're even interested in bringing in? 2) If so, other than obviously fixing the conflicts, is there anything you'd prefer I do with this to get it into a state where you'd be willing to pull it in?
Thanks!
I'm think that it would be better and more generic to use the wildcard match for this eg
<x-forwarded-for>*</x-forwarded-for>
or
<x-forwarded-for>192.168.*</x-forwarded-for>
should be just a simple change eg connection.c:820 if (fnmatch (xforward->ip, ip, 0) == 0) and the include at the top.
karl
@karlheyes I would definitely agree that wildcard support in the current x-forwarded-for config tags would be preferred; we had simply implemented this solution as a workaround for that not existing, as that would also perfectly solve the problem.
latest commit should now allow for the wildcard patterns.
karl
@karlheyes Looking at the commit, it's a brilliantly simple solution that I think will actually work perfectly for situations like Docker, where we have a trusted range of IPs that we know of.
I believe this satisfies the existing requirements and @CodeSteele can probably close this one out for now.
Thank you very much for your help and for your ongoing contributions to the world of FOSS radio. :)
Accomplished in e58e1de0f18422c71d54a74863acfc10e3c3a0e7
Makes it so we have the option to switch a configuration on/off that fixes #195.