Author: wiki.bugzilla
Description:
According to bug 5370 and bug 6003 (note Rob's comment there)
support for a throttle to new password requests is already in the code.
Please enable it on Wikimedia wikis. The need for it is supposed to be well known.
Version: unspecified
Severity: normal
psychonaut wrote:
See also Bug 6427, which proposes that blocked users/IPs should also be blocked
from requesting password reminders.
dodgy wrote:
Has this bug been fixed on mediawiki releases (e.g. 1.8.2?) or just for the wikimedia sites? Or is
there an extention for this? I sent many emails to people and they would not ever answer. MANY
wikis are getting hit with this and the wikimedia foundation just does not answer.
robchur wrote:
There's support for throttling *in the code*, but last I heard, it's switched
off on Wikimedia sites due to shared memory caching incompatibilities, or somesuch.
I guess we might need to think about some other throttling mechanism...
dodgy wrote:
Tim Starling claimed he fixed it back in October a week or two after 1.8.2 came out.
http://mail.wikipedia.org/pipermail/wikipedia-l/2006-October/045713.html
fixed with r17217 by Tim Starling. See [[MediaWiki:throttled-mailpassword]] too.
The actual default for Wikimedia sites is one password / 24 hours
dodgy wrote:
To Rob Church's comment, it appears to be throttling on wikipedia.
From looking through the r17217, it's clearly not going to officially be released until the next
MediaWiki release and r17217's changes may even have caused problems and so later update change(s)
(burried somewhere in the diffs) were needed.
Maybe the problem was that it wants some SQL changes. I see "ALTER TABLE user ADD user_newpass_time
char(14) binary;" as a definite, as well as some maintenance scripts of who knows what needs to be
run and what doesn't.
dodgy wrote:
It would also be good if they could add a throttling function so nobody can send email bombs, too.
dodgy wrote:
I hope this comes out in the next release. Messing around in undocumented, poorly described stuff can
damage SQL. I found that out the hard way when I tried running the compress old revisions program,
which it turns out has been broken since version 1.5 and it's not been mentioned but scantly on a few
forums only found after long google searching.
ayg wrote:
Releases are snapshot of trunk, so this will come out in the next release, 1.9,
in January.