New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
spamreports by IP does not recognize IPv6 IPs #1315
Comments
Wait, how the heck are we getting IPv6 IPs? This will cause a lot of trouble. Edit: Only thing I can figure is a user is talking to Cloudflare over IPv6, then CF talks to us over IPv4, but it sets the |
I don't know, I thought it was deliberate! I've been seeing them since at least our last code push. |
Cloudflare is my conclusion as well. |
So I guess the first question is: do we want to do IPv6 now or at all, through CF or otherwise? |
Well we don't have much choice if CF is giving it to us. Or, well, I
Mark Smith mark@qq.is On Sun, Mar 29, 2015, at 01:10 PM, Pau Amma wrote:
Links: |
What's involved in 1? 2 seems like a lot of work for something that is not futureproof... |
Comment IP address display already works fine, judging by http://www.dreamwidth.org/support/see_request?id=30590 |
We're up to 5 stuck open, which is somewhat distressing to spamwhackers. |
The IP address field in the spamreports table is limited to 15 characters, which means the IPv6 addresses in the existing reports are truncated and thus useless. If we remove or somehow modify the error check on line 245 of spamreports.bml, we ought to be able to at least load the page and close the bogus reports, but going forward we need to widen the field in the database in order to capture the full IP. |
This patch does two things: 1. Widens the column for IP addresses in the spamreports table from 15 characters to 39. An IPv6 address may contain 8 16-bit colon-separated hexadecimal codes for a maximum width of 8*5-1 = 39 characters. 2. Allows the spamreport page to load for any given IP value that is 39 characters or less. If the IP does not exist in the spamreports database, the "noreports" error will be shown. If the IP exists, the report may be viewed and closed, but the sysban option will not be presented unless it is a valid IPv4 address. Once we verify sysban support for IPv6, this clause may be removed. Fixes dreamwidth#1315.
This patch does two things: 1. Widens the column for IP addresses in the spamreports table from 15 characters to 39. An IPv6 address may contain 8 16-bit colon-separated hexadecimal codes for a maximum width of 8*5-1 = 39 characters. 2. Allows the spamreport page to load for any given IP value that is 39 characters or less. If the IP does not exist in the spamreports database, the "noreports" error will be shown. If the IP exists, the report may be viewed and closed, but the sysban option will not be presented unless it is a valid IPv4 address. Once we verify sysban support for IPv6, this clause may be removed. Fixes dreamwidth#1315.
Removed the proposed verify_ipv6 subroutine, since it doesn't capture all edge cases and isn't directly relevant to the main purpose of the change, which is to allow non-IPv4 spamreports to be closed. Also further widened the IP column of the spamreports table from 39 to 45 characters, just in case we ever receive any hybrid IPv6/IPv4 address formats.
[#1315] allow spamreports to handle IPv6 addresses
We're getting IPv6 IPs now, and /admin/spamreports by IP doesn't recognize 'em; it gives a "No such IP" error when you try to load the "by IP" view (eg, http://www.dreamwidth.org/admin/spamreports?mode=view&by=ip&what=2001:db8:0:1&state=open ) (IP replaced by an example IP).
The text was updated successfully, but these errors were encountered: