Topic on Project:Support desk

For my principally all-core, all-default MediaWiki website I use an about 24-characters root password and yet, by principle, I would still want to rate limit the number of times per x amount of time in which people can try to log in with my user name.

Is there a default, all-core way for rate limiting?

I don't want to set anything manually myself, just follow a rate limiting convention of the community, if there is one.

A simple, "turn on and keep going" approach for all sorts of rate limiting.

It is good for me because in my website there is, at least at this moment, only one registered user profile, which I myself operate and I wish to protect my profile from being hacked.

Of course, I protect as much as I can from DDoS, SQL injections, backdoors etc. but in the BFA/Rate limiting context I think that my website is still not fully covered and I seek a simple solution for that.

See Manual:$wgRateLimits and Manual:$wgPasswordAttemptThrottle

Hello @Ciencia Al Poder

Because the webpage you mentioned, Manual:$wgPasswordAttemptThrottle is much smaller and simpler I would like to try to start to implement what it describes; the problem is that I found any sentence in it unclear.

Limit password attempts to count attempts per seconds per IP per username.

Does this mean that a built in password tries rate limiting mechanism is on by default in all 1.14.0 and above MediaWikis?

> Does this mean that a built in password tries rate limiting mechanism is on by default in all 1.14.0 and above MediaWikis?

Yes, although on some versions it may only be enabled if $wgMainCacheType is set to something like CACHE_MEMCACHED or CACHE_ACCEL (and the cache is functioning correctly). I dont remember what the current cache backend for password throttle so im not sure if its still neccesary.

Lots of people also use extension:ConfirmEdit to add captchas to the login page after X failed attempts.

@Bawolff

From both your comment and from reading the first warning on Manual:$wgRateLimits I understand that in general, MediaWiki websites must have some version of caching in order to have rate limiting and that this is further true with specific types of caching for the default caching (enabled as long as $wgPasswordAttemptThrottle wasn't set to false).

I would like to ask MediaWiki developers here, why is caching even needed for rate limiting? From a modular standpoint, shouldn't these two features of a program be totally independent? Asked with desire to understand "what's going on" in this context.

for the default caching === for the default rate limiting*

Rate limiting in general works by tracking each time some actor does some action, and counting if it reaches a specific rate. This tracking needs to be saved somewhere. Devs may have decided to create specific tables in the database to store those values, but instead they decided to use the existing cache architecture for that. And that's why it requires a persistent caching.

honestly i dont know the current state. It used to require memcache explicitly but newer versions may fall back to db if that is unavailable. I dont know.

Reason we use caches is for efficiancy reasons. Rate limits are ephemeral, do not require strict durability (or other ACID properties), read a lot, and often written a lot even on pages that dont normally make db writes. In old versions of mediawiki the non memcached BagOStuff class didnt implement the inc method properly (since fixed afaik) i believe which is where memcached only came frkm.

I host my website on a shared hosting environment; I am not even sure Memcache is utilized there.

Anyway, I have changed CACHE_NONE to CACHE_MEMCACHED.

In MediaWiki 1.34.2, are there more elegant tests to test rate limiting besides pseudo-brute-forcing my own password?

After setting CACHE_MEMCACHED I had tremendous slowness in my website: Various webpages took around 11 seconds to come up, while it didn't happen with other websites so for now I brought CACHE_NONE back on.

@Bawolff

that happens if mediawiki cannot reach the memcached server (every request to it is waiting until timeout, which is like 10 seconds)

You need to setup memcached for this to work. Probably cant do that on shared hosting.

@Bawolff

Sadly php-apcu isn't installed on the shared servers of SiteGround so I shouldn't use CACHE_ACCEL but they do include Memcached as part of their own wider internal caching tool:

siteground DOT COM /tutorials/supercacher/memcached/

But I am not sure I want to work with Memcached; it might be too heavy for a relatively small website like of myself, thus I might need to avoid CACHE_MEMCACHED also.

From Manual:Performance tuning I understand that my only other option is CACHE_DB which might be best for me as I am interested in the smallest amount of cache needed for rate limiting (otherwise I would most likely not use cache at all).

I invite you and anyone else in the community to opine what approach to take in a case like mine.

setting main cache to CACHE_DB may make your site slower than CACHE_NONE. Im not sure what too heavy means. It should work fine for a small website (make sure youtell mw correct host and port of memcached server). The main reason Apc is reccomended is just the install steps are simller

@Bawolff

By "too heavy" I meant that as far as I know in some scenarios of small websites with say <=1000 webpages, the very processing of Memcached might take too much resources that would better spent on serving content directly.

Moreover, In my shared hosting environment, while with CACHE_NONE I have enabled Memcached module via SiteGround, purged its cache, travelled to some relevant webpages and then reloaded them --- all webpages came up slightly slower in 2-3 seconds if not in the regular 0.5-1.5 seconds although I assumed that Memcached will give some effect of its own ------ I then set CACHE_MEMCACHED and the original problem of waiting to timeout came back, indicating that SiteGround's Memcached and MediaWiki don't communicate properly.

I later understood from a SiteGround staff member that their Memcached installation is WordPress oriented and generally doesn't communicate with MediaWiki.

you probably have to set Manual:$wgMemCachedServers correctly.

> By "too heavy" I meant that as far as I know in some scenarios of small websites with say <=1000 webpages, the very processing of Memcached might take too much resources that would better spent on serving content directly.

The truth is complicated and depends on a lot of factors, but generally speaking this is probably not true.

I take back what I wrote before that I later understood from a SiteGround staff member that their Memcached installation is WordPress oriented and generally doesn't communicate with MediaWiki, because another staff member commented and said this is wrong and that Memcached should work with all websites.

A sysadmin confirmed that the command memcached -d -l 127.0.0.1 -p 11211 -m 64 works properly and that memcached service is running as expected on port 11211:

baseos | u462-yfqqwgwaqfra@us153.siteground.us:~$ telnet localhost 11211
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.

@Bawolff I tried to read Manual:$wgMemCachedServers and I didn't understand anything I read.

Is there any chance for some explanation for a Memcached layman such as myself about what I most probably need to do to get Memcached communicate properly with MediaWiki?

Perhaps @HappyDog would like to add something for the sake of documentation.

Hi there,

I'm guessing I was brought into this because I originally created the Manual:$wgMemCachedServers page. Unfortunately, I don't have any help to offer - that page was created by compiling various bits of information from other sources, not from a position of authority on the subject.

Sorry I can't help any further.

-- HappyDog (talk) 14:28, 10 February 2021 (UTC)

Thanks HappyDog !

I think I figured out what @Bawolff meant that I need to do:

1. To change CACHE_NONE to CACHE_MEMCACHED
2. To change $wgMemCachedServers = []; to something like:

$wgMemCachedServers = [
  "127.0.0.1:11211", # one gig on this box
  [ "192.168.0.1:11211", 2 ] # two gigs on the other box
];

Because Memcached listens to port 11211 in my system, I think I pretty much done all needed configuration.

I do want to know how to test that my changes are proper; I didn't find a "Testing" (or similar) chapter in Manual:Memcached.

well copying that directly out of the manual page is probably wrong. You need to include the correct host/port pairs.

@Bawolff my problem is that I don't know what should be second pair; the first one appearing in the manual 127.0.0.1:11211 seems to be identical to in my hosting environment, but what is the second one? Putting SITE'S_IP:11211 as the second pair didn't make Memcached to work.

The second pair is when you have a second memcached. If you only have one, you should only put the first value.

Example:

$wgMemCachedServers = [
  "127.0.0.1:11211"
];

Thank you Bawolff and Ciencia; if anyone has anything to add, please do.