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.
* dev-auto-reset-triggers to test auto resetting trigger action at end of each hour references #130
* migration and comment change
* migrateVersion change
-refactor name/tripcode/capcode handler to separate function
-use new methods in places like news, announcements and new posts
-more structure and logic for post editing
some random guy
