nice, all of the spam is gone.
e-mail works so you should be able to recover your account here
1 Like
Hi, I may be a bit late to the party here. I wanted to contribute to some of the pages, specifically several of the official map’s pages that are barren. Noticed I needed administrative access to edit. I’m rather new to the whole wiki thing but I hate fandom wiki. I’m wondering if there is any update to getting the site operational, or at least, a way for me to edit some of the pages!
hello! you’re free to contribute; any help updating the content is very much welcome. the wiki is operational.
you should be able to create an account and start working on it right away. perhaps you found a protected page? most pages are unprotected and open to any user.
could you link me so i can check? otherwise it might be this lingering config:
we needed a heavy-handed approach because the wiki was getting a lot of bot spam, but i thought that was already solved. could you check the php code @Spirit ? EDIT: the config was indeed blocking users. fixed it.
i still have ssh access, so i went ahead and fixed the config
users can edit now! 
2 Likes
And I just realised why older accounts cannot login. I dropped the private infos before giving you access as an over sensitive precaution and forgot to restore them. D'oh!
On it right now 
Hm, I managed to reset my password now that I have a mail address set again for my user. But when I log in, any subsequent request to the wiki gives an error:
[08ef57209a3cac2510ac9ada] /wiki/Main_Page TypeError: hash_equals(): Argument #1 ($known_string) must be of type string, null given
Backtrace:
from /srv/quakewiki/w/includes/session/CookieSessionProvider.php(144)
#0 /srv/quakewiki/w/includes/session/CookieSessionProvider.php(144): hash_equals()
#1 /srv/quakewiki/w/includes/session/SessionManager.php(542): MediaWiki\Session\CookieSessionProvider->provideSessionInfo()
#2 /srv/quakewiki/w/includes/session/SessionManager.php(248): MediaWiki\Session\SessionManager->getSessionInfoForRequest()
#3 /srv/quakewiki/w/includes/Request/WebRequest.php(867): MediaWiki\Session\SessionManager->getSessionForRequest()
#4 /srv/quakewiki/w/includes/session/SessionManager.php(167): MediaWiki\Request\WebRequest->getSession()
#5 /srv/quakewiki/w/includes/Setup.php(494): MediaWiki\Session\SessionManager::getGlobalSession()
#6 /srv/quakewiki/w/includes/WebStart.php(85): require_once(string)
#7 /srv/quakewiki/w/index.php(50): require(string)
#8 {main}
Google found me https://phabricator.wikimedia.org/T397423 but I am not sure if that applies (and what it means).
Maybe I need to restore more than just the user.user_email column?
I've just updated MediaWiki to 1.43.6 (dec/2025) and checked that I can still log in, log out, edit and watch pages.
you might've restored user_token by accident which is a cookie that should have expired long ago. drop the contents of that column and clear your browser cookies.
you can either do it directly on the database or do it though the maintenance scripts. something roughly along the lines of:
php maintenance/run.php invalidateUserSessions --user '*'
// OR
UPDATE user SET user_token = '' WHERE user_token IS NULL;
// OR maybe
UPDATE user SET user_token = NULL;
i'm not sure so make backups!!
it might also be related to the weird cache settings this wiki runs (CACHE_MEMCACHED for one skin?) so try dropping the memcached cache immediately after you make any database changes and before logging in:
$ telnet localhost 11211
> flush_all
# php maintenance/run.php invalidateUserSessions --user 'Spirit'
Failed to invalidate sessions for user Spirit | CAS update failed on user_touched. The version of the user to be saved is older than the current version.
Wikimedia\Rdbms\DBTransactionError from line 1470 of /srv/quakewiki/w/includes/libs/rdbms/loadbalancer/LoadBalancer.php: Commit failed on server(s) localhost: Cannot execute query from MediaWiki\Maintenance\MaintenanceRunner while transaction status is ERROR
#0 /srv/quakewiki/w/includes/libs/rdbms/lbfactory/LBFactory.php(333): Wikimedia\Rdbms\LoadBalancer->commitPrimaryChanges()
#1 /srv/quakewiki/w/maintenance/includes/MaintenanceRunner.php(811): Wikimedia\Rdbms\LBFactory->commitPrimaryChanges()
#2 /srv/quakewiki/w/maintenance/includes/MaintenanceRunner.php(710): MediaWiki\Maintenance\MaintenanceRunner->shutdown()
#3 /srv/quakewiki/w/maintenance/run.php(51): MediaWiki\Maintenance\MaintenanceRunner->run()
#4 {main}
PHP Notice: Uncommitted DB writes (transaction from MediaWiki\User\User::saveSettings) in /srv/quakewiki/w/includes/libs/rdbms/database/TransactionManager.php on line 564
PHP Notice: DB transaction writes or callbacks still pending (MediaWiki\User\User::saveSettings) in /srv/quakewiki/w/includes/libs/rdbms/database/Database.php on line 3207
Directly editing the DB and flushing memcached did nothing, same result after logging in.
user_touched is 20180829171140 for "Spirit". I tried to set it to the future just to see what would happen. Same error with the invalidateUserSessions script.
looks to me like you're trying to restore the user data of an older backup or something that has a different schema than the mw 1.43.6 i installed last week. that'll definitely break things.
i don't really have the time or mental bandwidth to check it out right now, sorry.
1 Like
Totally understandable! Sorry for the mess on the system.
I really only restored the user_email column, with plain SQL UPDATEs. I guess it is some breakage from old times that is resurfacing. 
The site was DDOSed by the AI bot horde. The CPU was pegged at 100%. 2 million requests from 850000 unique IPs in the past week. This crap makes hosting anything on the open web no fun anymore. 
I added a mandatory cookie which seems to work well enough for now.
D'oh, this will block good agents like Google too.
I don't have the energy to find a better solution. If someone is willing to take over quakewiki.org, please shout!
spirit!!! oh no i hate these fucking ai crawler bots that hog servers. i've had my own share of issues on my own mediawiki instance and i've had success with anubis and go-away but, as you say, the false positive rate is too large for comfort, so they do block some known good bots.
nginx's rate limiting is pretty good, too, but not for ~850000 unique ips.
while i can take care of quakewiki, i don't have a vps or a box to keep it running. is the current vps insufficient for the amount of traffic going through it? should we think moving out of mediawiki? it is quite the large php project after all, and perhaps static pages would fit quakewiki since its read heavy but there's rarely any writes.
tldr: i'm available to look after quakewiki but i don't have hosting
i checked and there's been 420358 requests today and 331220 requests yesterday. the site is seriously under heavy load.
What if we set Cloudflare as the nameserver for quakewiki.org and enabled their WAF?
It would only require updating the NS records at the registrar, and in return we'd get automatic filtering of common threats like SQL injection and XSS, bot management to block scrapers and spam bots, plus free SSL, DDoS mitigation, and caching, all on their free tier.
https://www.cloudflare.com/learning/ddos/glossary/web-application-firewall-waf/
Cloudflare's/US mass internet surveillance is not coming anywhere near any website that I am responsible for. I have respect for user privacy.
@nitoducci would you be able to self-host if you got the money for it? I guess the community would provide sponsoring for its hosting costs, as they did in the past years.
1 Like
based spirit
yeah i can plug in a server over here, i have the hardware, space and bandwidth (gigabit) but i'd pay for the server's electricity and internet. thus, it might be cheaper to rent? vultr? ovh? hetzner?
i've been thinking about it and i think the easiest fix is to restrict diff, history, login and edit pages from robots, since most of the dumb requests are stuck on comparing every single version against each other.
on how to identify what is a "robot", i propose any user agent that contains "@", "bot" or "http" (case insensitive). i've never seen a proper consumer browser with those UAs, so we'd have no false positives.
a permanent fix would be, perhaps, to either get a more powerful machine to tank the crawlers, or get a lighter software solution that can serve more requests on the same machine. i assume there's no escaping crawlers on the internet nowadays, hence these choices.
all http requests with the mentioned criteria are now rejected with http 403:
$HTTP["useragent"] =~ "(?i)(bot|@|http)" {
$HTTP["url"] == "/w/index.php" {
$HTTP["querystring"] =~ "(type=signup|type=login|days=30|Special(%3A|:)RecentChanges)" {
url.access-deny = ("")
}
}
$HTTP["url"] == "/w/api.php" {
$HTTP["querystring"] =~ "action=feedrecentchanges" {
url.access-deny = ("")
}
}
}
i've been looking at it for a bit and this lowered the server load, because the requests come in but they are not served.
2 Likes
Thanks so much for looking into it!
Most probably use fake user-agents, it's the residential proxy scraping horde. Afaik anubis can block these bots fairly well but I am too dumb to set it up.
Oh I meant self-hosted as in "on a server somewhere", not "in your basement" Until minutes ago it was running on a Hetzner CX11 (1 CPU, 2 GB RAM, 20 GB SSD), I have now upgraded to a CX23 (2 CPU, 4 GB RAM, 20 GB SSD) for actually a few cents less. Oops, didn't pay attention at the recent price changes! It's ~4 € per month.
1 Like