Skip to content
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

Closed
rahaeli opened this issue Mar 26, 2015 · 9 comments · Fixed by #1393
Closed

spamreports by IP does not recognize IPv6 IPs #1315

rahaeli opened this issue Mar 26, 2015 · 9 comments · Fixed by #1393
Assignees

Comments

@rahaeli
Copy link
Contributor

rahaeli commented Mar 26, 2015

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).

@zorkian
Copy link
Member

zorkian commented Mar 26, 2015

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 X-Forwarded-For to be the IPv6 address. Mind. Blown.

@rahaeli
Copy link
Contributor Author

rahaeli commented Mar 26, 2015

I don't know, I thought it was deliberate! I've been seeing them since at least our last code push.

@alierak
Copy link
Member

alierak commented Mar 26, 2015

Cloudflare is my conclusion as well.

@pauamma
Copy link
Contributor

pauamma commented Mar 29, 2015

So I guess the first question is: do we want to do IPv6 now or at all, through CF or otherwise?

@zorkian
Copy link
Member

zorkian commented Mar 30, 2015

Well we don't have much choice if CF is giving it to us. Or, well, I
suppose our choices are:

  1. Plumb IPv6 support (ouch, but ultimately, the right decision)
  2. Put in some hook in Apache::LiveJournal that sees IPv6 and converts
    them to some RFC1918 address like 10.x and then store the IPv6 in
    some database table, then we can fix the display layer in a few
    places to show the IPv6 but still internally store them as unique
    IPv4s (this assumes we don't get more than 24 bits of IPv6
    addresses... I know, a bad assumption, but probably true for a while)

Mark Smith mark@qq.is

On Sun, Mar 29, 2015, at 01:10 PM, Pau Amma wrote:

So I guess the first question is: do we want to do IPv6 now or at all,
through CF or otherwise?

— Reply to this email directly or view it on GitHub[1].

Links:

  1. spamreports by IP does not recognize IPv6 IPs #1315 (comment)

@rahaeli
Copy link
Contributor Author

rahaeli commented Mar 30, 2015

What's involved in 1? 2 seems like a lot of work for something that is not futureproof...

@pauamma
Copy link
Contributor

pauamma commented Mar 31, 2015

Comment IP address display already works fine, judging by http://www.dreamwidth.org/support/see_request?id=30590

@azurelunatic
Copy link
Contributor

We're up to 5 stuck open, which is somewhat distressing to spamwhackers.

@kareila
Copy link
Member

kareila commented May 21, 2015

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.

@kareila kareila self-assigned this May 21, 2015
kareila added a commit to kareila/dreamwidth that referenced this issue May 23, 2015
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.
kareila added a commit to kareila/dreamwidth that referenced this issue May 23, 2015
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.
kareila added a commit to kareila/dreamwidth that referenced this issue Jun 8, 2015
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.
zorkian added a commit that referenced this issue Jun 23, 2015
[#1315] allow spamreports to handle IPv6 addresses
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging a pull request may close this issue.

7 participants