Only factor in the user ID/name/sig instead of anything that
might happen to touch the user row.
Bug: T136678
Change-Id: I004790a017c68cfcff6729f6fbfd0f79b6904c20
A recent patch, I66be724d, introduced a regression that no longer
applied user selected namespaces to the search engine. Fix that up so we
give the correct responses to api rqeuests.
Change-Id: I8e5e180cb143ae3cddeb12f51bc7aae75b20fe58
* ApiQueryAuthManagerInfo will differentiate between preserved linking
data and a preserved createRequest.
* ApiQueryAuthManagerInfo will indicate the preserved username, if any,
because the client will have to pass that back to action=createaccount.
* ApiClientLogin won't tell about the confusing
CreateFromLoginAuthenticationRequest returned on RESTART responses.
* Explain how 'preservestate' works in ApiAMCreateAccount's auto-doc.
* ConfirmLinkSecondaryAuthenticationProvider will filter out requests
that can no longer be used (i.e. if it was for linking the account
that got used for creation).
* All the complicated code in AuthManager::beginAccountCreation() was
trying to deal with allowing the client to pass only the
CreateFromLoginAuthenticationRequest. That was dumb, removed it.
* Added methods to CreateFromLoginAuthenticationRequest to indicate its
status with respect to different kinds of preserved state.
* Increase accuracy of the AuthenticationResponse::$createRequest doc.
Change-Id: I726d79de18e739d6e60c1eea51453433c21ba207
This patch introduces a way for SearchEngine implementations to expose
specific search profiles useful to fine-tune the various behaviors related to
search.
A SearchEngine can expose a list of profiles by overriding
SearchEngine::getProfiles( $profileType ), profileType stands for the type of
profile being customized. Two types are added in this patch:
- completion: exposed by ApiQueryPrefixSearch and ApiOpenSearch to control
the behavior of the algorithm behind "search as you type" suggestions.
- fulltext query independent profiles: exposed by ApiQuerySearch to customize
query indpendent ranking profiles (e.g. boost by templates/incoming
links/popularity/...)
This patch allows api consumers that might have been confused by fuzzy
suggestions to switch to stricter profiles and to officialize the behavior
behind the hidden param cirrusUseCompletionSuggester. Or to control the
fulltext ranking behaviors like cirrusBoostLinks=(yes|no).
The list of profiles can be discovered by using ApiSandbox/ApiHelp and is totally
controlled by search engine implementations.
Bug: T132477
Change-Id: I66be724d8975976c98c91badbf421f237e014f89
Follows-up 9af38c0. Token must match ApiRollback, RollbackAction,
Linker, and WikiPage. (This should not be in different 5 places!)
This broke the "PILT" gadget.
Bug: T136375
Change-Id: Ia6b6879a952925ec52fa627ba57991bc87fd947a
* Set API response metadata on the AuthenticationRequest metadata so it
is output as an assoc generally.
* Remove the 'image' field in AuthenticationRequest::getFieldInfo()'s
response, since we ended up not using it anywhere.
* Make it so meta=authmanagerinfo can be used on private wikis without
logging in, so action=clientlogin can be used to log in.
** This generalizes the exception for meta=tokens that was added in
I83dafb030.
* ApiAuthManagerInfo needs the "messageformat" parameter.
* ApiAuthManagerInfo shouldn't be publically cached, since the responses
vary depending on session state.
Change-Id: Iea5ddb4ef9febed18f16a7ae8314968026f39148
The former sometimes show up in the logs as they were causing
CentralAuth to use the master but the expectations treated
the request as a GET request. This makes things more
consistent.
Bug: T92357
Change-Id: I55bf3139c68f5926fe67a51cf0eb1b2ffe55d17b
Similar to WatchAction (converted in commit 77cdf1919).
* Make FormAction::getFormFields not abstract.
In most cases this will just be an empty array.
* Convert RollbackAction from FormlessAction to FormAction and implement the
required error handling scenarios (mostly moved out of from the old method, or
duplicated from the WikiPage method where necessary).
* In most cases the in-between form is never used since a JavaScript handler
takes over the link and uses the API over AJAX instead. In the no-js fallback
(as well as for any existing tokenless rollback links) copy the GET parameters
into the form for re-submission as POST (plus token, added by HTMLForm).
* Remove the distinction between WebUI and API tokens. This stronger token salt made it
unnecessarily complex and was only there because it used GET until now. This streamlining of
tokens matches what we already do for 'watch', 'edit', 'patrol' and other actions.
* Fix form submission bugs when 'from' query parameter is missing.
- Ensure the required 'from' query parameter is present before showing a form.
No need for the user to submit a form we know will fail.
- Plain GET request to action=rollback (with no parameters) is now a 400 Bad Request
instead of a form that would fail when submitted.
- Submitting the form without 'form' field now correctly says why it failed.
Previously it emitted a session error, which was a lie.
Bug: T88044
Change-Id: Ia457802fec2e90573c8e7d552bc1f3cee258f10b
In:
* apihelp-clientlogin-example-login2
* api-help-authmanager-general-usage
Also fix a typo in api-help-authmanager-general-usage.
Change-Id: I2a9f6c46c992fda9a21068dd789043d5ef626311
While rate limiting has been applied to moves via the web UI since rate
limiting was first added, it appears that it was overlooked when ApiMove
was created.
This follows the same model as is followed by the web UI: each
submission to ApiMove is one "hit" for the rate limiter, even though
that submission might result in multiple pages being moved (e.g. the
page, its talk page, and its subpages) depending on the options and user
rights.
Bug: T132874
Change-Id: I564d8bfcc7dd3ad6d92dbbc33519a589697c0d4e
Signed-off-by: Chad Horohoe <chadh@wikimedia.org>
Take into account that the tag might have parameters.
Bug: T123653
Change-Id: Ie9799f5ea45badfb4e7b4be7e7fbc1c35cc86f26
Signed-off-by: Chad Horohoe <chadh@wikimedia.org>
The header is intended for use with XMLHttpRequest when the request
might be part of an XSS. The hook is for extensions that might need to
add additional checks of some sort.
Bug: T98313
Change-Id: I0e5f2d3b29a79a12461dc33c90c812a56810f536
Signed-off-by: Chad Horohoe <chadh@wikimedia.org>
In $wgAddGroups, $wgRemoveGroups, $wgGroupsAddToSelf, and
$wgGroupsRemoveFromSelf, boolean true in place of an array of groups to
allow adding/removing is shorthand for "all groups". Handle this
appropriately in action=query&meta=siteinfo&siprop=usergroups.
Bug: T135467
Change-Id: I6ae61ef14ac7932e3369155c56bad60a9d72060d