***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".
This prevents prolems like `/` giving 404 in devel mode (when
`static/html/index.html` is missing) or `/captcha` redirecting to
`/captcha/` (then breaking).
authenticated: same as `user != null`
user.authLevel, user.ownedBoards, user.modBoards: refreshed by sessionrefresh on
each request anyways, so it doesn't make much sense to store them in the session
store too.
* properly escape goto parameter
* do not redirect to anywhere, only to the same server, no query parameters
This should still allow valid targets, like `/account.html`,
`/boardname/manage/whatever` while disallow things like `https://othersite.com`.
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.
some_random_guy