findLinks() doesn't have a third parameter and an undefined one
wouldn't be all that useful even if it did.
Change-Id: I250b558d7b97a6355b3d86b71b3a37399b3c6eb0
This broke account creation for apps.
< anomie>bd808: Very likely $wgRequest !==
$loginForm->getContext()->getRequest() in SimpleCaptcha::addNewAccountApiForm(), so when it
uses $wgRequest to check later on it doesn't see the parameter renames made by that hook
function.
This reverts commit 23c6f2f04f.
Change-Id: I793e7a987944d14c3be0eba4c4361793183a62b9
The captchaId will be deleted, so a second call to SimpleCaptcha::passCaptcha() will
be always false, even if the User solved it correctly.
Bug: T94276
Change-Id: I2bc7766c023d7bd3a6c471f83b87ef0f09cbfaea
Added a check for 'badcaptcha' ratelimit. This enables administrators
to limit users trying to solve captchas just by playing around.
By default there is no ratelimit set, it has to be set explicitly in
LocalSettings.php.
Bug: T48292
Change-Id: I8fc66f9884288c4596b8b4045010cdaa421a1412
The code for the hook is passing in an empty new-text, so there's no
point in parsing that and the existing page text for links.
We pass false to shouldCheck's $isContent parameter (and an empty string
for $content) because getting a Content would break compatibility with
1.21, which we specifically preserved in I9529b7e8.
This also kills two entirely-unused parameters to the recently-added
SimpleCaptcha::editShowCaptcha().
Bug: T88661
Change-Id: Ie8a2d4da4c5bf0dcc8977172debbeb5913b56191
CAPTCHA classes should always be possible to detect the actual action,
which triggered the CAPTCHA. E.g. to add special fields in getForm().
Change-Id: Ie95305b2e6dcbf527a23c92613755092185e6a05
Captcha.php inserts captcha in the header of Userlogin and Usercreate template.
This leads to inconsistent view because js,if enabled, moves the captcha before
submit button. Now the captcha is inserted at the 'extrafields' parameter just
before submit button in both the templates,for uniformity of view.
JS functionality in
resources/src/mediawiki.special/mediawiki.special.userlogin.common.js migrated
to backed in FancyCaptcha.class.php, so that the FancyCaptch is already styled
and positioned before 'submit'.
Depends on I82c68814e79cbc5aa250a308862c59fcbb6fd527
Depends on Ie95305b2e6dcbf527a23c92613755092185e6a05
Bug: T85192
Bug: T87190
Change-Id: If9a68aaee2cf98d63647816ccc8fc0bad12ca3d3
Insert Captcha direct after click on Edit over editpage buttons, instead of
show after click on save. If the captcha was incorrect or empty, show
error message at old captcha position.
Bug: 19648
Change-Id: Ia3bb66f98aa84bb6efb7a1e42fbc203b401e99b8
ConfirmEdit was tripling the API save time, because it was parsing the
entire content twice to evaluate whether the addurl trigger is hit.
While I was here, I stopped using the deprecated non-Content hooks. The
new hook, EditEditFilterMergedContent, does not pass an EditPage object,
which means that Title or WikiPage objects need to be passed around
instead. Also, since EditPage::showEditForm() cannot be called with no
EditPage object, use a EditPage::showEditForm:fields hook instead.
If non-wikitext content is edited, assume that the regex trigger is not
hit.
For further architectural details, see the associated core change:
I4b4270dd868a . MW_EDITFILTERMERGED_SUPPORTS_API is a constant
introduced to detect the presence of the associated core change.
Also, in APIGetAllowedParams, set the allowed parameters even if we are
not on the help screen. This allows API users to submit their CAPTCHA
answer without it failing with an "unrecognized parameter" error.
Compatibility with MediaWiki 1.21 is retained, compatibility before that
is dropped.
Change-Id: I9529b7e8d3fc9301c754b28fda185aa3ab36f13e
The old style does not cooperate well with the new pretty forms in
core MediaWiki, and arguably this should be done like this anyway.
Bug: 63606
Change-Id: Ifbe41ee5787bd4ed9e6144c06cd1d16f72354061
Requires core update I6ae34c0 to actually send the message key back
in the error response. On older MediaWiki versions, behavior should
remain unchanged.
Bug: 60008
Change-Id: If9cc08e44d1d2efacf817b8c6cbb2d71a4e8b692
Hooks used:
* AddNewAccountApiForm
* AddNewAccountApiResult
This adds a 'captcha' section to the results with the same format
as we provide for editing; you'll get this for instance at the
same time as you do a first-request that prompts for a token.
No modification to the result status is included; presence of
the 'captcha' section is assumed to be enough to prompt the client
to fetch and render the captcha prompt.
Failure to pass a captcha will return an API error message; a
subsequent commit fixes problems with that error message being
hard to machine-read.
Note that logic from inside Captcha::confirmUserCreate has been
pulled out to Captcha::needCreateAccountCaptcha so we don't
send captcha information to users who don't need it.
Requires core changes: If5b7dab8
Sample API client: https://github.com/brion/api-createaccount
Bug: 46072
Change-Id: Id628defaeab2bf5979ca8f4284d14fc42d9c3e46
ConfirmEdit triggers a captcha when users without the appropriate
userright add new external links. But sometimes there are links that
these users should be able to add without a captcha, e.g. other wikis in
the same farm, so MediaWiki:Captcha-addurl-whitelist allows wiki admins
to whitelist links matching regular expressions.
However, these whitelist entries are automatically prefixed with
"^https?:\/\/+[a-z0-9_\-.]*". While this is usually what is wanted, it
prevents wiki admins from whitelisting other types of links such as tel:
or urn:. Following the example of TitleBlacklist, this change adds
options delimited with <> to the whitelist lines, and adds an option
'noprotocol' that causes that line to be prefixed with only "^" instead.
Bug: 56485
Change-Id: Ia0d484f7a4670df2c7121d1284e4fcf969e818c3
It wasn't setting a size at all so defaults to 20. It only needs to be
3 characters wide, this sets size to 5. This fixes the layout of new
Login and Create account forms in Monobook and should be benign
elsewhere. I29672b63d12cd380d7b00cad3449807da76e4188 made a similar fix
to FancyCaptcha.
Bug: 50387
Change-Id: Ia3098d7c2e28072f52c1cd6615667a96389660dc
The ReCaptcha module was not injecting its parameters at all, so they
were not showing up in the auto-generated help. This is now fixed.
Also, the API recently added a new parameter to the APIGetAllowedParams hook
to differentiate between fetching the allowed parameter list for help
output and fetching it for processing within the module. ConfirmEdit
only needs to inject the parameters for the former, so it should check
this parameter if available.
Change-Id: Ia8c9a8b882ee3480b71bfb3f2345475506549819
* Removed unused globals and local variables.
* Use Message class.
* Remove PHP4-ism from recaptchalib.php.
* Remove superfluous newlines.
* Add missing semi-colon in ext.confirmedit.asirra.js.
* Fix up some documentation.
Change-Id: I8916003d083a8c00aeabc9e485cc9a50030f0982
Left setting of wpCaptchaId and wpCaptchaWord in core. Can't think of a sane way to check and set them via an extension (subclass and override, or a hook). Annoyingly APIEditBeforeSave doesn't pass the params array
