-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
yurik@svn.wikimedia.org wrote:
Revision: 22488 Author: yurik Date: 2007-05-27 16:50:24 -0700 (Sun, 27 May 2007)
Log Message:
API: Enabled API login throttling (with amidaniel's help)
This is code duplication -- why are you duplicating functionality that's in the low-level authentication already?
- -- brion vibber (brion @ wikimedia.org)
In the IRC discussion a while back, I was told that there is no timeout of any sort. If the login timeout is already implemented in the core login, the whole exercise was pointless, and will be reverted.
On 5/29/07, Brion Vibber brion@wikimedia.org wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
yurik@svn.wikimedia.org wrote:
Revision: 22488 Author: yurik Date: 2007-05-27 16:50:24 -0700 (Sun, 27 May 2007)
Log Message:
API: Enabled API login throttling (with amidaniel's help)
This is code duplication -- why are you duplicating functionality that's in the low-level authentication already?
- -- brion vibber (brion @ wikimedia.org)
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGXH0OwRnhpk1wk44RAjIJAKCvNAzn3swxZ4sQ4m9y8NTEZSUorACfeNIy amSjn15MdgePXlBKeaK8A3E= =vbV1 -----END PGP SIGNATURE-----
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 5/29/07, Yuri Astrakhan yuriastrakhan@gmail.com wrote:
In the IRC discussion a while back, I was told that there is no timeout of any sort. If the login timeout is already implemented in the core login, the whole exercise was pointless, and will be reverted.
No, the log-in timeout is not in the core login; as far as I'm aware, there is not even a timeout on the standard log-in (the idea of throttling log-in attempts was suggested and rejected). The captcha business, which prevents the brute-forcing of passwords via SpecialUserlogin, is in the *extension* ConfirmEdit. It might be a very good idea to migrate this into the core, but until such time it's going to have to be secured on each individual component. It would seem quite illogical, however, to have devoted all this effort into securing Special:Userlogin against brute-forcing while leaving the API log-in wide open.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Daniel Cannon wrote:
On 5/29/07, Yuri Astrakhan yuriastrakhan@gmail.com wrote:
In the IRC discussion a while back, I was told that there is no timeout of any sort. If the login timeout is already implemented in the core login, the whole exercise was pointless, and will be reverted.
No, the log-in timeout is not in the core login;
Yes it is.
as far as I'm aware, there is not even a timeout on the standard log-in (the idea of throttling log-in attempts was suggested and rejected). The captcha business, which prevents the brute-forcing of passwords via SpecialUserlogin, is in the *extension* ConfirmEdit.
Depends on what you mean by "in".
The code that implements it is in the extension, because it's part of an extension.
It happens in the core authentication, and thus happens for both Human-HTML and API interfaces.
The captcha itself will only display for the human-HTML interface once triggered, but the lockouts would apply to both.
It might be a very good idea to migrate this into the core, but until such time it's going to have to be secured on each individual component. It would seem quite illogical, however, to have devoted all this effort into securing Special:Userlogin against brute-forcing while leaving the API log-in wide open.
Maybe that's why it's not the case, then. :)
- -- brion vibber (brion @ wikimedia.org)
wikitech-l@lists.wikimedia.org