still todo migration
"ips" will make more sense for staff now
qrange/hrange no longer need to be stored
bypass still work like before. will have .BP suffix, normal ips are .IP
filtering and stuff still works
bans page will now show .*'s in the cloaked view for range bans
in future version, this allows (even for those who cant see raw ips):
- modlog, bans, post hisory filters including per-range
- directly input ips/range cloak to ban, without selecting a post
- upgrading existing bans from single to ranges
todo: rename every "hrange" and "qrange" with nrabge and brange? narrow/broad? would need to migrate a bunch of existing db shit for bans, posts, etc probably a pain in my ass
and remove a leftover console.log
***DO NOT USE***
This still has some issues and needs testing.
- needs updated nginx configs added, expects "TOR" in the x-country-code header under a separate vhost
- need to make sure bans work properly still
- need to implement system to prevent captcha ddos, since i cant just to IP ratelimit now
- im 99% sure post history of tor users is broken if viewed by non-global staff
- manual input ban form will also be broken for non-global staff
- could still use some improvement on the middleware having a little more complicated flor for tor users
But for the most part it works. Basically it will use the bypass id of a tor user as their "ip".
Currently jschan takes the IP address as a string from the `X-Real-Ip` header,
which based on the frontend proxy configuration, OS settings, etc. can take
various forms:
IPv4 addresses can be given in normal IPv4 dotted notation (e.g. `1.2.3.4`) or
as an IPv4-mapped IPv6 address (e.g. `::ffff:1.2.3.4`). The problem is, that in
the latter case, node's `isIP` will report 6, so the code will try to split it
along colons, breaking hrange and qrange.
With IPv6 addresses, it's possible to elide runs of zeroes, so `::1` and
`0:0:0:0:0:0:0:1` (and also `0000:0000:0000:0000:0000:0000:0000:0001`)
represents the same address. Since it's pretty easy to get a /64 IPv6 block, a
spammer can abuse it, by spamming from `a🅱️c:d::1` (`qrange=a🅱️c:d`,
`hrange=a🅱️c`), then from `a🅱️c:d::1:1` (`qrange=a🅱️c:d:`, `hrange=a🅱️c`),
`a🅱️c:d::1:1:1` (`qrange=a🅱️c:d::1`, `hrange=a🅱️c:d`) and
`a🅱️c:d:1:1:1:1` (`qrange=a🅱️c:d:1:1`, `hrange=a🅱️c:d`). He practically got
two hranges and qrange is pretty much pointless for IPv6 addresses.
This change uses the `ip6addr` package to parse IP addresses and convert it to
some canonical form. This means:
* IPv4 and IPv4-mapped IPv6 addresses are converted to normal IPv4 notation.
* Zero are not elided in IPv6 (so you'll never see `::`).
* IPv6 addresses are not zero padded (so `..:1` instead of `..:0001`).
* Even though it's not documented, it seems like `ip6addr` always generates
lower-case letters.
This will unfortunately mean that some IP hashes may change after the update.
Normal IPv4 hashes will most probably remain the same though.
Thomas Lynch
some random guy