I've been thinking about this for quite some time, and don't you think that the data results should last longer than 3 months? I mean, why not just stick to 6 months instead of 3 as it just feels drastically too short. You don't have to agree with me on this if you don't want to. It's just a suggestion, not a requirement.
Extension talk:CheckUser/Archive 2
This is a perennial question. I believe the WMF considers it a breach of personal data policy to permit searching the records further back. Technically it is quite possible to extend the period and it would help combat the fiercly growing abuse of Wikipedia - at least on en.Wiki - for commercial purposes. ~~~~
That could be true either way.
You can change that by setting $wgCUDMaxAge to a longer period.
If you want to change that on WMF wikis, the request should be discussed and approved first, but anyway this talk page is not the place to take this discussion. Maybe try a bugreport?
Exactly. The way MediaWiki is used on WMF projects is driven by the WMF and it's unlikely they will approve any changes to their policy even if asked time and time again by a majority RfC from their volunteer communities. Hence making a request at Phab would be a waste of time. The simple $wgCUDMaxAge setting is free for anyone to use who is using MediaWiki for other purposes.
Oh yeah. Although I'm not a Steward on any of these wikis.
I believe we have adequately explained the situation with the use of CU on WMF and non-WMF websites powered by MediaWiki. ~~~~
Hello!
I'm trying to use this hint of documentation:
"To allow this tool to log successful and failed login attempts as well as logouts, set $wgCheckUserLogLogins to true"
But my Investigate page shows only successful login attempts
How to switch on unsuccessful attempts to logs?
Failed login attempts are tagged under the IP address that made the login attempt. This means that when using Special:Investigate on an account, you need to also include the IPs in the investigation.
You do this by clicking the "Show all users on this IP" button in the three dots menu. This button is shown at https://commons.wikimedia.org/wiki/File:IP_options.png
When I enter a username in Investigate, it takes a very long time for the username to be recognized.
What version of MediaWiki are you running and what is your internet connection like? The username doesn't take too long to be recognised for me, but relies on an internet connection to find the suggestions.
In all European Union countries, automatic IP storing is subject to the RGPD. And can therefore only be carried out after explicit consent has been obtained from each user. Cf website of European commission.
Does this extension meet these conditions ?
To caveat this answer: I am not a lawyer. This answer if my personal understanding of this as a developer who only vaguely understands GDPR. I would suggest that if you need a concrete answer that you consult lawyers familiar with GDPR.
My personal opinion:
- This is used on Wikimedia Foundation wikis (which includes Wikipedia) and therefore probably meets these requirements as lawyers for the foundation will have checked the requirements.
- The data is only collected and then stored when the user performs an action that they should have to affirmatively perform (for example, making an edit). When this is done, the user is presented with text along the lines of By publishing changes, you agree to our Terms of Use. In this document is contained the information about the collection of IP addresses for abuse mitigation.
As such I would suggest that this extension meets the requirements as long as your wiki has a privacy policy / terms of use that a user is presented with when trying to edit. However, as I've said above, this is my opinion only and may be completely wrong.
Hopefully my comment is helpful.
The fact that Wikifoundation is doing it is no guarantee of legality. Lots of "big websites" are in breach of the RGPD without worry as long as a legal complaint isn't lodged.
But yes, I suppose putting a clear warning in the "Term of Use" at account creation and editing should be ok.
Just finished troubleshooting an odd condition where Special:RecentChanges completely stopped updating after an "upgrade" to MediaWiki 1.39, reinstalling the supposedly latest-and-greatest version of all installed extensions, including this one.
Debugging with LocalSettings.php settings: $wgDebugDumpSql = true; $wgDebugLogFile = "/var/log/mediawiki/debug-{$wgDBname}.log";
I'd see [DBQuery] attempts to add records to recentchanges, searchindex and the like; I'd also see an attempt to add a record to cu_changes. The latter attempt would fail because cuc_actor apparently does not exist; PHP would dump the call stack and then exit. The end result was no updates to Special:RecentChanges, Special:NewPages, Special:NewImages and possibly others.
Attempting
ALTER TABLE `cu_changes` ADD `cuc_actor` INT NOT NULL AFTER `cuc_title`;
and rebuilding (on a one-time basis) with rebuildrecentchanges.php seems to bring Special:RecentChanges back to life. I'm seeing this issue on multiple wikis and yes, that is despite running maintenance/update.php
Why is this happening? 204.237.89.128 23:22, 3 May 2023 (UTC)
What database type are you using?
The update path for the three different supported database types are different. However, all three seem to be working on a visual inspection (so I would need to know what database type you are running to try to re-produce).
Also what version of MediaWiki were you running before updating to 1.39?
PHP 7.4.29 MariaDB 10.6.12
A direct jump from MediaWiki 1.35 to 1.39.3 using maintenance/update.php
Thanks. I aim to take a look at this in the next few days.
Haven't been able to take a further look at this due to IRL time pressures. May be able to look some point this week.
Chiming in to say I have had the same problem. I recently updated from 1.35. Here's my current setup:
| Product | Version |
|---|---|
| MediaWiki | 1.39.4 |
| PHP | 7.4.33 (fpm-fcgi) |
| MariaDB | 10.4.20-MariaDB-1:10.4.20+maria~buster-log |
| ICU | 65.1 |
I was too hasty with my previous comment. I went back to the installation instructions and realized that I didn't properly follow the directive "If you have installed other extensions without running php maintenance/update.php, run that first." I guess at the time, since I was using all the same extensions before I upgraded from 1.35 to 1.39, I hadn't done this. In other words, I had run php maintenance/update.php, but I had not run it with the CheckUser extension disabled. Thus, I decided to:
- Disable the extension
- Run
php maintenance/update.php - Enable the extension
- Run
php maintenance/update.phpagain
Lo and behold, everything is working just fine now. So that's mea culpa for not following instructions!
Good to hear that worked.
I use Cloudflare on my site, is it possible to get real IP addresses with this tool?
The real IP should be present in the X-Forwarded-For header. See Extension:CheckUser#XFF_Format
Hey so I'm not sure if this the proper location for reporting bugs, but the WHOIS function appears to have suffered from link rot. http://ws.arin.net/whois/?queryinput= needs be updated to their new URL: http://whois.arin.net/ui?queryinput=
I think I've fixed it in this change.
I get this error using SSH
"1064: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'TYPE=InnoDB' at line 25 (localhost)". wikirio@wikirio.com.br [~/public_html/extensions/CheckUser]# run php install.php -jailshell: run: command not found
You are supposed to “run php install.php”, mind the formatting, :-) i.e. write just
wikirio@wikirio.com.br [~/public_html/extensions/CheckUser]# php install.php
without the “run”.
Is CheckUser supposed to log the IPs for every account creation or only some? We're having the issue right now of a spambot creating numerous accounts, but most are not appearing in the CheckUser tables, only the normal MediaWiki user creation logs.
Note: we solved this problem, and it's not a problem with the software. Our mobile servers inadvertently didn't have CheckUser installed.
Is there a way to install this without access to phpMyAdmin and the command prompt? I can create new tables with SQLyog but that's it. If looked into the install.php and it seems that I can do that but I want to check first.
Download the SQL files mentioned under the section on installing without command prompt access. You basically need to create those tables according to those specifications.
Thank you, everything worked fine and CheckUser is running now without problems.