All deprecated ApiResult methods are removed. These have been deprecated
since 1.24 or 1.25, and the only users remaining in Gerrit are wrapped
in backwards-compatibility checks and so should not be being called.
ApiBase, ApiFormatBase, ApiMain, and ApiQuery methods for generating the
pre-Ib14c00df help text are removed. Nothing has called these for a long
time, and only Flow implemented them in any way. Deprecated methods for
providing the text for such help, such as getDescription(), haven't been
removed yet, though, since some extensions still call some of them.
Change-Id: I3ca7c98174b4a3f6f67f2b023e0f4446637e7a84
Useful for search engines that allow users to customize search profiles.
Depends-On: Icd577c8ebc6e162befe30bde4fe276e633d2e434
Change-Id: I471cd090730d2a25cb70d622ec3bebbe9583118c
An @ in the username caused the password to be treated as a bot password,
but apparently some real usernames still contain it. Try both logins
instead. Security considerations are the same as for the other bot
password syntax: the length check makes sure we do not provide any
information on a timing side channel about the password unless it is
extremely long.
Change-Id: I58f42544a08c3208c41f54cfae932632d9c5affa
If a client submits data that is not NFC-normalized Unicode or that
contains C0 controls other than HT, LF, and CR, it gets normalized before
the API ever sees it. Which can lead to difficult-to-handle bugs when,
for example, a title is subject to normalization so the client can't
find the specific title it submitted anywhere in the response (T139130).
This patch does two things:
* Detects when normalization was applied to an input value (at the
MediaWiki level, anyway; if PHP or earlier does it we're just out of
luck) and add a warning to that effect.
* For ApiPageSet's 'titles' parameter, split into the individual titles
and add them to the 'normalized' list in the response. This requires
encoding the pre-normalized strings to avoid ApiResult's own
normalization.
Bug: T29849
Bug: T144071
Change-Id: I215fd3edd7a5e1b45292e60768bf6dd5ad7f34de
When a multi-valued parameter's value begins with U+001F, the values
will be split on that character instead of pipes. This will be useful
for things such as action=options&change= or meta=allmessages&amargs=.
Since MediaWiki doesn't otherwise accept C0 control characters
(WebRequest::getVal() replaces them with �), there's no possibility that
this will conflict with a literal use of U+001F.
Special:ApiSandbox and mw.Api are updated to make use of this, with the
latter having an option to disable the behavior in case something is
depending on [ 'foo', 'bar|baz' ] turning into 'foo|bar|baz'.
Pipe is still used as the separator when the value doesn't begin with
U+001F, and will be forever since it's generally more human-friendly and
is needed for backwards compatibility with basically every API client in
existence. The requirement that the value begin with U+001F, rather than
simply contain U+001F, is to avoid clients having to somehow
special-case "param=foo|bar" where that's intended to be a single value
"foo|bar" rather than two values "foo" and "bar".
Bug: T141960
Change-Id: I45f69997667b48887a2b67e93906364a652ace5a
* Set an indexed tag name in ApiParamInfo and ApiAuthManagerHelper.
* Use 'key' instead of 'message' for the (not yet used) non-BC
ApiErrorFormatter.
Change-Id: I07f0a690e263b34e09210673241af8bf750cbd1b
Revert commit 23e5cdb503
temporarily so Pywikibot users can catch up with API changes
Bug: T121527
Bug: T142155
Change-Id: I3879a5d76a1727dd653daeebc79d4d9cabd0332e
In I6f987db this parameter was inadvertantly renamed to qiprofile. The
qiprofile is something different, and is also a BC break. The BC break is
pretty minor, for a randomly chosen day this looks to be used 157 times
out of 28.7M requests, but since this really isn't a qiprofile rename
it back to what it was.
Change-Id: I1cc07945888c15ea4b4c9596eea447b706606fae
We have a number of parameters that are pretty much the same between
these different search api's. Lets make them actually the same by
sharing the definitions, and then letting individual classes tweak them
as needed by removing the offset, or adjusting the max limits as
necessary.
Change-Id: I6f987db8ecb63dc943b4d2518bfe3703c677448e
Database queries used to get user's watchlist items in API are quite
complex due to number of options oferred by the API.
Generating the query is moved to WatchedItemQueryService.
ApiQueryWatchlistRaw no longer contains database-related code.
Simple user watchlist item lookups should use WatchedItemStore.
ApiQueryWatchlistRaw tests have been introduced in
I9c07aa237607143985f0efe20ed0065d2bde27e4
Bug: T132566
Change-Id: I875a92074b52c00ac11db1fa05615abbf5262ab1
This moves generating of a complex Watchlist and RecentChanges
related query to a WatchedItemQueryService class.
ApiQueryWatchlist class no longer contains any database-related
code.
Bug: T132565
Change-Id: I5a5cda13f8091baa430ac1a8e2176e0efd1ae192
The unit tests spend nearly half of their run time resetting the user table for
each test. But the majority of tests do not depend on the user table having the
exact value that the setup code resets it to, and do not need to modify the
user objects they require to run.
Fix that by providing an API for tests to get User objects, and to indicate
whether the User object will be subject to destructive modification or not.
This allows User objects to be reused across multiple unit tests.
Change-Id: I17ef1f519759c5e7796c259282afe730ef722e96
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>
Changes here are:
* action=login is deprecated for use other than bot passwords
* list=users will indicate if a missing user name is creatable.
* Added action=query&meta=authmanagerinfo
* Added action=clientlogin is to be used to log into the main account
* action=createaccount is changed in a non-BC manner
* Added action=linkaccount
* Added action=unlinkaccount
* Added action=changeauthenticationdata
* Added action=removeauthenticationdata
* Added action=resetpassword
Bug: T110276
Bug: T110747
Bug: T110751
Bug: T32788
Bug: T67857
Bug: T28597
Bug: T76103
Change-Id: I244fa9b1e0623247d6d9fa30990411c6df94a496
This implements the AuthManager class and its needed interfaces and
subclasses, and integrates them into the backend portion of MediaWiki.
Integration with frontend portions of MediaWiki (e.g. ApiLogin,
Special:Login) is left for a followup.
Bug: T91699
Bug: T71589
Bug: T111299
Co-Authored-By: Gergő Tisza <gtisza@wikimedia.org>
Change-Id: If89d24838e326fe25fe867d02181eebcfbb0e196
* Speed up password generation and verification by setting MWOldPassword as the
default password type. Do this once, in MediaWikiTestCase::makeTestConfig(),
rather than in five different places.
* Rename '$pwhash' to '$passwordHash', for consistency. It's ugly to have both
'$passwordFactory' and '$pwhash' in the same scope.
* Make TestUser::setPasswordForUser() check first whether the desired password
is already set. This is actually the common case, since the password is reset
in the setup code for every test, but only a few tests actually change the
password.
Change-Id: I423f09ff7472b6cbde21cb709ea7c7ef9e298f18
Note: This change does not add tests for deleted revision/log data
(comment, action, user). These should be added in a follow up.
Change-Id: Ia76c39134564c477aa46ccb7b6595173410b0251
Iec4ed4c8 made it so addCoreDBData() only gets called once. Which is
nice, except for the fact that it means any test that puts
'user_groups' into $this->tablesUsed is going to cause UTSysop to no
longer be a sysop, so any later test that expects it to be one is going
to mysteriously fail.
The fix is to make resetDB() actually clear out the 'user' table when
requested, but then to re-call addCoreDBData() so UTSysop is still
there.
This might break extension tests if they're relying on the 'user' table
never being cleared even if it's specified in $this->tablesUsed, but
hopefully that's not often the case.
Bug: T132411
Change-Id: If251739fd486544f54a0c07edcc24aeef0998342
Depends-On: I0546a4f18e0751d209b6b7c6cd42973f25828313
Depends-On: I4924ae941b3844b39dd3f44c6986c3bf29b0d62a
This reduces the runtime of database-bound tests by about 40%
(on my system, from 4:55 to 2:47; results from Jenkins are
inconclusive).
The basic idea is to call addCoreDBData() only once, and have
a addDBDataOnce() that is called once per test class, not for
every test method lie addDBData() is. Most tests could be
trivially be changed to implement addDBDataOnce() instead of
addDBData(). The ones for which this did not work immediately
were left out for now. A closer look at the tests that still
implement addDBData() may reveal additional potential for
improvement.
TODO: Once this is merged, try to change addDBData() to
addDBDataOnce() where possible in extensions.
Change-Id: Iec4ed4c8419fb4ad87e6710de808863ede9998b7
The plan here is to take it out of 1.27.0-wmf.12 and put it back in
1.27.0-wmf.13.
Since BotPasswords depends on SessionManager, that's getting temporarily
removed too.
This reverts the following commits:
* 6acd424e0d SessionManager: Notify AuthPlugin before calling hooks
* 4d1ad32d8a Close a loophole in CookieSessionProvider
* fcdd643a46 SessionManager: Don't save non-persisted sessions to backend storage
* 058aec4c76 MessageCache: Don't get a ParserOptions for $wgUser before the end of Setup.php
* b5c0c03bb7 SessionManager: Save user name to metadata even if the user doesn't exist locally
* 13f2f09a19 SECURITY: Fix User::setToken() call on User::newSystemUser
* 305bc75b27 SessionManager: Don't generate user tokens when checking the tokens
* 7c4bd85d21 RequestContext::exportSession() should only export persisted session IDs
* 296ccfd4a9 SessionManager: Save 'persisted' flag in session metadata
* 94ba53f677 Move CSRF token handling into MediaWiki\Session\Session
* 46a565d6b0 Avoid false "added in both Session and $_SESSION" when value is null
* c00d0b5d94 Log backtrace for "User::loadFromSession called before the end of Setup.php"
* 4eeff5b559 Use $wgSecureCookie to decide whether to actually mark secure cookies as 'secure'
* 7491b52f70 Call session_cache_limiter() before starting a session
* 2c34aeea72 SessionManager: Abstract forceHTTPS cookie setting
* 9aa53627a5 Ignore auth cookies with value 'deleted'
* 43f904b51a SessionManager: Kill getPersistedSessionId()
* 50c5256352 SessionManager: Add SessionBackend::setProviderMetadata()
* f640d40315 SessionManager: Notify AuthPlugin when auto-creating accounts
* 70b05d1ac1 Add checks of $wgEnableBotPasswords in more places
* bfed32eb78 Do not raise a PHP warning when session write fails
* 722a7331ad Only check LoggedOut timestamp on the user loaded from session
* 4f5057b84b SessionManager: Change behavior of getSessionById()
* 66e82e614e Fix typo in [[MediaWiki:Botpasswords-editexisting/en]]
* f9fd9516d9 Add "bot passwords"
* d7716f1df0 Add missing argument for wfDebugLog
* a73c5b7395 Add SessionManager
Change-Id: I2389a8133e25ab929e9f27f41fa9a05df8147a50
User keeps most of its token-related methods because anon edit tokens
are special. Login and createaccount tokens are completely moved.
Change-Id: I524218fab7e2d78fd24482ad364428e98dc48bdf
None of this works and it's been long begging for a mercy kill.
All it does is waste contributor time on updating deprecations
in the dead code. I imagine we wouldn't reuse much of this
code if we're ever going to reimplement it.
Bug: T119336
Change-Id: Ibd26a4bea621857aac77823017e9be9b7dc52cca
Sigh, PHP. You allow for an array to have string "1" as a key (e.g. when
casting from object to array), but then you do everything wrong when
trying to deal with it.
Bug: T123663
Change-Id: I49f09901a69aab39ca1519bbe9e41267bf9a1216
