[2.1] Address issues with proxy lookups#9229
Conversation
|
I'm still doing testing... (I tested as best I can without actually having a proxy!)
|
Signed-off-by: Shawn Bulen <bulens@pacbell.net>
Signed-off-by: Shawn Bulen <bulens@pacbell.net>
|
Ready for review/test. My core tests are below: |
|
Note that the old CIDR lookup algorithm works... I'd never seen it done nibble-by-nibble before like that. I still prefer the rewrite:
|
|
Can we get the 3.0 equivalent. I also really hate that we are creating new functions, but for simplify_ip we can't avoid it due to repetition. Unless we use an Anonymous function. Mostly because then we have to introduce that into 3.0 with backwards compatibility function |
|
OK, I'll work on the 3.0 version. May take me a few days. I'll also figure out the backwards compatibility stuff in that PR. I'd really like it if someone could test this - from behind a real proxy. I had to emulate things... |
|
Its possible we can avoid the backwards compatibility needs. One of the 2 functions is only called once, so we could just inline its check. The other function we can anonymize it and assign it to a variable in the function, like |
Fixes #9143
I took a stab at this.
Changes:
@todo's in there noting outstanding ipv6 work was needed. This was a 'nuke it from orbit and start over' scenario; it needed simplifying.CONCERN:
Note that the ban check validates against BOTH the member_ip and member_ip2, i.e., both the proxy and the end user IP. Also note that the proxy may be using a valid 'localhost' IP. So... When we get this working, a ban on a user by IP can effectively ban a valid 'localhost' IP, i.e., a huge swath of (or even all...) proxy traffic.
Here:
SMF/Sources/Security.php
Line 181 in 2ce5fbc
I believe we should only check the end user in the ban check, not the proxy server...
If agreed, I'll add this to this PR...
If we wish to proceed with this I'll submit the 3.0 version once approved.