sql-enwiki/ipcheck

IPCheck - Proxy Checker

ipcheck's Issues

Do access checks based on global account data rather than local account data

@SQL-enwiki said IPCheck can be used by anyone with an account registered before 30 days and having more than 500 edits on the project that is selected before logging in.

Having IPCheck doing this on global account data would remove this additional step when logging it, make this awesome tool more convinient for user.

Example API query: https://en.wikipedia.org/w/api.php?action=query&format=json&meta=globaluserinfo&guiuser=SQL&guiprop=editcount.

Button for some big wikis

Since the login dropdown defaults to enwiki, it is pretty annoying I have to scroll every time I browse the tools (I don't use it daily and Safari does a pretty good job at scrubbing the auth data for not-visited-for-long sites) I have to scroll and find meta from 800 wikis. Life would be more beautiful if we have some buttons for "click here to log in from enwiki" "or Meta" "or Commons" then the dropdowns.

Add geolocation from proxycheck.io

Per title.

Scoring platform

I'm a little hesitant on this one. I see on-wiki a lot, people will point to IPQS results and treat it as a gospel "That's a proxy!!!" and block / refuse to unblock based on those results.

That being said - this platform takes a lot more into account than just IPQS. We are able to offer a more accurate proxy / vpn / webhost score than one service alone - by design.

What weighting should api-platforms get?
What weighting should DNSBL's get?
What weighting should Hola detection get (if the hola port is open, and/or detection last occurred within 86400 seconds)?
What weighting, if any should portscan results get (they may not be available on every check as well - as they're going to be optional very soon)?

Allow WMF Staff to access the tool

Problem
WMF Staff sometimes need to make judgements on IP Addresses and are unable to access the tool.

Proposed Solution
Usernames that end with (WMF) should be able to access the tool without restriction.

Make access denied error message more descriptive

This is what I get when I log in with my WMF account. Not telling much, perhaps adding "Only users with more than 500 edits and older than 30 days can use this tool" is possible?

Ignore whitespace

When looking up an IP ignore any whitespace before or after the IP, if there is whitespace in either place it will break the search for example: https://tools.wmflabs.org/ipcheck/index.php?ip=8.8.8.8+

Persist preloaded IP address through OAuth prompt

If I am logged into the IPCheck tool, and load a URL such as https://ipcheck.toolforge.org/index.php?ip=129.205.113.145, I am immediately taken to the results page for that IP address. This is the desired behaviour.

If I am not logged into IPCheck, I get redirected to an OAuth prompt. I accept the OAuth prompt, and on my return I am sent to https://ipcheck.toolforge.org/index.php, which prompts me to input an IP address. The tool should remember the requested IP address through the OAuth prompt, thus if I arrive at the tool with a request for a specific results page, I should be able to accept the OAuth prompt and be directed back to the requested results page.

The developer in me wants to suggest adding the IP to check to $_SESSION, then on return to the tool check whether there's something in $_SESSION and run that check instead of returning to the search box - there may be a better way that fits more closely with the tool's architecture though.

Cache results

Each time an IP is queried, the results should be cached in a serialized fashion. I recommend caching for one week only (the graph on this page, as old as it is, suggests that to be a reasonable duration). There should also be a way to invalidate the cache on demand (perhaps requiring a CAPTCHA check).

The advantages are:

1. Faster response time for subsequent queries for that IP while the cache lasts
2. Fewer queries to upstream services
3. Less possibility of being blocked by upstream services

Any caching mechanism would do. Perhaps we should rewrite the code to use a framework with caching support (Symfony has a cache, and Laravel has supports many caching mechanisms, as does CodeIgniter)

Geolocation

Add geolocation, or at least a link to a geolocator

Add proxycheck.io new features

From: https://proxycheck.io/emails/newsletter-april-2019.html

Specifically city and coords, as well as risk assessment

Wiki URL Get parameter

Should probably have a 'wiki' get param so that the links are more localized.

Default to enwiki?

Spamcop bl

Consider adding spamcop dnsbl, See:

https://www.spamcop.net/fom-serve/cache/297.html
https://www.spamcop.net/fom-serve/cache/291.html

Curl error

Rendered HTML just says "Curl Error:"

Possibly relevant logs:

2020-03-10 18:58:22: (mod_fastcgi.c.421) FastCGI-stderr: PHP Warning: file_get_contents(https://www.iphunter.info:8082/v1/ip/*IPADDRESS*): failed to open stream: HTTP request failed! HTTP/1.1 400 Bad Request

Possibly related, not sure why it would trigger a curl error however:

2020-03-10 18:58:22: (mod_fastcgi.c.421) FastCGI-stderr: PHP Warning: mysqli::__construct(): (HY000/2002): php_network_getaddresses: getaddrinfo failed: Name or service not known in /data/project/ipcheck/public_html/oauth.php on line 95

Line 95 being:

$my_oa = new mysqli('meta.web.db.svc.eqiad.wmflabs', $ts_mycnf['user'], $ts_mycnf['password'], 'meta_p');

Will update this ticket as I investigate.

Specialized API key for WHOIS tool

I filed whym/whois-gateway#13 to include IPCheck as a useful tool but as it stands there's the OAuth verification that any user will have to go through (and then it loses the IP query, which is bad behaviour). I think it should be possible to create a specialized API endpoint that directly allows the tool to fetch a few results from IPCheck.

Need a geolocation alternate - IPHunter is no longer viable.

It looks like IPHunter has removed time-unlimited free plans, and moved to 15 day trials.

My IPHunter trial has expired. This impacts geolocation.

I think I can use proxycheck.io - https://proxycheck.io/blog/post/asn-data-improved-with-city-and-coordinate-information but I'm not sure how useful that will be.

Access Control

For the main app - there should be some form of access control - preferably oauth.

What level should be required for access?

EC? (Not all wikis have this, but a check for 30/500 shouldn't be too hard to write)
Admin? (Perhaps this could be a base requirement to allow portscanning?)

Resource managemernt

Implement a resource management system using the groundwork laid in stats.php

As a user uses 5% of our current lowest provider's allowed queries, start throttling / delaying requests more aggressively until they reach 10%, at which point no further queries will be allowed until the beginning of the next calendar month.

Possible alternate would be adding hourly/daily/monthly hard limits per user. This may be preferable to intentionally degrading the service, as well as being easier to implement.

User preferences

User preferences, such as preferred block template

API

Write documentation for the API.

Write Access control for the API.

Allow comments on IP's

We should allow comments on IP's - perhaps privileged (e.g. user/checkuser) for links to the cuwiki / etc.

This should be trivial to implement.

This is one of many possible blockers for #29 / #30 .

Allow users to provide their own API key for some providers?

This could be useful for helping to keep down shared query usage.

Allow users to enter more than one IP at once

When you're looking at XY accounts, it's frequently useful to paste a bunch of IPs to the tool and get only those that are proxy, for instance. Originally thought about writing a sister tool asking IPCheck for the data through its API, but maybe it's good idea to bundle this into IPCheck?