This allows extensions (e.g. TemplateSandbox in I77a9aa5a) to better
interact with the ApiParse and ApiExpandTemplates modules.
Change-Id: I72d5cf8e0b86e4250af1459219dc3b42d7adbbb8
At least avoid the first parse in doEditContent()/filters which
never has the revision set either. The second parse cannot be
avoided in doEditUpdates() however.
Bug: T136678
Change-Id: I12d2c3bbe1b21ad2ed9a484745d976ad62475e0d
* Users are likely to save after they inspect and review their changes.
The buttons to do so are also located below the edit summary box.
* This obsoletes the backend stashing on preview. Most of those parses
would have been useless due to being per-section only. Also, some
extensions like the Graph extension disable stashing for "preview"
output anyway. Simplify the code by removing that method.
Bug: T136678
Change-Id: Ied77bdbd191dd9267d4295b0fa7b942f65b062db
As requested in T62835#1794915, this logs requests that have an Origin
header that isn't whitelisted and have "session" cookies (defined as
"cookies that SessionManager says to vary on").
Change-Id: I3e34ff1e3a0a3f63c709ee95aa5cf8309fbc4367
This may negatively affect performance and the whole purpose of the
hook (making it possible to reject an edit from an extension while
providing detailed error information in the API result) has been
invalidated by 09a5febb7b, which lets
EditFilterMergedContent do this too.
I think it was intentional that the hook was called with just the text
passed to action=edit API. Making it actually be called with the text
that's going to be saved would require more work (e.g. for
automatically resolved edit conflicts, T73947).
Very few extensions use this hook. I'm fixing AbuseFilter to use
EditFilterMergedContent in I30c1e3d0a6c10888e6ac53745313434474663cce,
we should also review ConfirmEdit, ProofreadPage and SpamBlacklist to
see what behavior they really expect.
This reverts commit be97167ab6.
Change-Id: I62713419496bcf57364a8fa9de93c0c8ddc3e91c
Per https://grafana.wikimedia.org/dashboard/db/edit-stash, the
proven_* cases are almost never hit. Simplify the code to avoid
complexity and slow link table queries.
Change-Id: I3f8bd79a80ddb26c6188b1a301c08766e38f6ad4
This allows any external site to do with CORS what they can already do
with jsonp: submit a request that will be processed as if logged out.
This is done by accepting '*' as a value for the existing 'origin' URL
parameter that is currently required in order to do any CORS requests
against MediaWiki.
The response to such a request will specifically include
"Access-Control-Allow-Credentials: false" to instruct the browser not to
send cookies or other authentication data, and further the API will
apply all the same restrictions (forcing an anonymous user and
forbidding certain actions such as token fetch) that it currently does
for jsonp requests.
Bug: T62835
Change-Id: I30e359fb23f0511242dfb4bff68718668947aaf5
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
This aims to solve all the problems and fulfill all the use cases.
It allows the dialog to be configured for Wikimedia Commons without
hardcoding anything, and it should be flexible enough for third-party
use. The default configuration should be sane for any wiki.
The file upload dialog can be configured using $wgUploadDialog.
See DefaultSettings.php for documentation. Example configuration for
Wikimedia Commons: Id56370e2334c8fe34e88180356232b48c244b7c4.
Configuration is loaded using ResourceLoaderUploadDialogModule for
local uploads or using ApiQuerySiteinfo (action=query&meta=siteinfo)
for uploads to a foreign wiki. Custom localisation messages may be
loaded using action=query&meta=allmessages.
Renamed messages:
upload-form-label-own-work-message-local -> upload-form-label-own-work-message-generic-local
upload-form-label-not-own-work-message-local -> upload-form-label-not-own-work-message-generic-local
upload-form-label-not-own-work-local-local -> upload-form-label-not-own-work-local-generic-local
upload-form-label-own-work-message-default -> upload-form-label-own-work-message-generic-foreign
upload-form-label-not-own-work-message-default -> upload-form-label-not-own-work-message-generic-foreign
upload-form-label-not-own-work-local-default -> upload-form-label-not-own-work-local-generic-foreign
Deleted messages, moved to WikimediaMessages in Id2977e19330aeaf854157d4355cd17e5dc72f16a:
upload-form-label-own-work-message-shared
upload-form-label-not-own-work-message-shared
upload-form-label-not-own-work-local-shared
Bug: T118097
Bug: T120998
Bug: T121632
Bug: T121633
Bug: T127895
Change-Id: I3017b8f09c27625deb7a92d6f667895b71cc0637
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 still handles users editing inclusions themselves, but is
more relaxed in terms of edits by other users to the inclusions.
Bug: T134620
Change-Id: I6c0d189957481dfb6da0e73581b1d5b69fd3a352
Every permission included in managechangetags is really harmless and can be reverted
in short time, except of the permission to irriversibly delete tags. That's why
this should be excluded in an additional permission that other wikis can restrict
deletechangetags more than other tag management actions.
Bug: T133811
Change-Id: Ieb9199f2c6997316ae3468ff5a92b2d2456c012f
When the code was written, $status->getErrorsArray() would return the
Message objects unchanged. But I0deaa988 broke that and apparently
didn't bother fixing callers.
Now that I'm trying to actually use it for something, I find it's
broken, so I fixed it.
Change-Id: I763729c5bdd63448b50229774ef1f9d12cfb795d
* This is useful for logic that decides what DB (master/slave) to use
based on the nature of the web request. It could also be used to
enforce clear read/write distinctions via exceptions if DB_MASTER
is misused.
* Also fixed two IDEA errors while editing this class.
Bug: T134608
Change-Id: I43f4bc06c19d823d7d1ffd9cee8bbe60563c7f82
Further down, this was already somewhat being checked.
On L112, `verifyTitlePermissions` is called, which will fail
if the user is blocked. However:
* This was not being checked during stashed uploads
* Block just "happens" to be part of that check: the intent is
actually to verify the file title. The error is treated as
recoverable (the title can be changed), but it isn't (the
user can't unblock himself in this process)
Bug: T111228
Change-Id: I9cbf250a0b92c3daa3a0843f2257cc049abd3923
Patrolmarks permission is enough to request patrol information, as it's coded
in useRCPatrol() and useNPPatrol().
Change-Id: I4115bdbbcaf6764d71784efe2d8ac63cc77ce770
With $wgExperimentalHtmlIds = true Sanitizer::escapeId( 'main/credits' )
is equal to 'main/credits'. This generate a duplicate ID.
This change generates the additional <span> only with
$wgExperimentalHtmlIds = false.
Bug: T134155
Change-Id: Ie5d692b7b166030b2bc5c426b44608d981274cd0
* The wrong time method was used, and it also was not set.
* Bumped the threshold a bit while at it, which was basically
0-5 minutes before.
Bug: T133332
Change-Id: Ide3e66f551aa6e50410c562e5c917141d59b7f64
Instead of just counting cache hits and misses, segment the counts by reason,
so we can differentiate (for example) timestamp-based cache hits from
staleness-check-survivor cache hits. I want this data so I can determine
whether increasing the cutoff for timestamp-based hits from 3 to 5 seconds has
a substantial enough impact to warrant the slightly weaker consistency.
Also changed 'cache-hit' to 'cache_hit'. MediaWiki normalizes the dash to an
underscore anyway, but the normalization is there for dynamically-constructed
key names (or name segments). In the case of hard-coded values, it is desirable
for the code to be as close as possible to the final form of the metric name,
to simplify metric lookup.
Change-Id: I0cd61da9746e3ca3695e23200f698b8b1371798c
execute() references the static self::getInfo, which therefor cannot be
overriden by the subclass ApiQueryVideoInfo. Preferably, we'd fix the
implementation to not require this subclassing, but this will make
that transition easier. Use late static binding to make sure the
subclass implementation can be used.
Change-Id: Iab2d01abb9f9b3b799123d8ee344ea139e476576
Th API handles parameters of type 'user' as page titles, which resulted
in silently dropping # characters and anything following them.
Reject such usernames explicitly instead.
Bug: T132852
Change-Id: Iba8061b20d5e25de80ff30d09eb53939c97cdaac
wikimedia/html-formatter is already present in mediawiki/vendor
as of 3954ca36ce3cbedc76c1763ad2694320c1327ce6.
Bug: T125001
Change-Id: Ie98096e5e3d325cde583bc66b21b8b41f2bba8b2
Status::getWikiText is used for internal logging, api error messages and
maintenance scripts. All this places are usually in english, so pass an
english language to getWikiText.
Change-Id: I3010fca8eb5740a3a851c55a8b12e171714c78f7
Adds a preference in the Watchlist section for watching uploaded files
for an account. Also works from API-based upload methods, so
UploadWizard and other tools should work fine.
Bug: T33313
Change-Id: If962e667de12b35904b2d1b2d9e99c26b588ec2a
Remove "\\" in namespacing. This is a Doxygen compatibility hack but
does not seem needed anymore, Doxygen reads namespaced class names
correctly, see e.g. https://doc.wikimedia.org/mediawiki-core/master/php/classMediaWiki_1_1Services_1_1ServiceContainer.html
PHP IDEs, on the other hand, were broken by the double backslash.
As an unrelated small doc fix, add parameter docs to PermissionError
constructor (parent has different arguments so the inherited
documentation is wrong).
Change-Id: I6da0f512b8c84f65fd20e90e4617108fe6a8fcd2
We use "IP address" consistently instead of "IP", but this was never
applied to the "range" addition.
Change-Id: I02fecf0b9e6a5b90f7a24209c7a1cdce64060b23
This lets us capture some basic endpoint timing data that is
lacking now, such as upload API call time.
Change-Id: If0627e2d78d82b22ed6bdaaa0fa7fe5f20ef50b1
This matches the behavior of Special:LinkSearch, and makes it more
likely to give sensible results for non-normalized input.
Bug: T130912
Change-Id: I2f60dd48fdfc24108110a24ad41b297ece7f33df
When MediaWiki encounters an unhandled exception, the error message it produces
includes a randomly-generated token, which allows the exception details to be
looked up in the error logs. This is useful but narrow: would it not be useful
to have the ability to retrieve all log records associated with a particular
request, rather than just exception details? (Hint: yes.)
So: introduce the notion of a request-global unique ID, retrievable via
WebRequest::getRequestId(). When MediaWiki is behind Apache + mod_unique_id
(which provides the same facility) or some other software which sets a
UNIQUE_ID envvar, the value of that envvar is used as the request ID.
Otherwise, it is a randomly-generated 24-character string.
The request ID supplants exception-specific IDs; MWExceptionHandler::getLogId()
is deprecated, accordingly. The request ID is also added as an annotation to
all Monolog-processed log records, and is exposed client-side as 'wgRequestId'.
This allows developers to associate a page view with log records even when the
page view does not result in an unhandled exception. (For the WMF, I also
intend to add it as an annotation to profiling data).
The request ID is not a tracking token; it does not persist, and it is
associated with a backend request, not with a particular user or a particular
session. Like the data in the NewPP report, the request ID is designed to be
cacheable, so that if, for example, a developer notices something weird in the
HTML, s/he can associate the output with a backend request regardless of
whether the response was served from the cache or directly from the backend.
Some prior art:
* https://httpd.apache.org/docs/2.4/mod/mod_unique_id.html
* http://api.rubyonrails.org/classes/ActionDispatch/RequestId.html
* https://github.com/dabapps/django-log-request-id
* https://packagist.org/packages/php-middleware/request-id
* https://github.com/rhyselsmore/flask-request-id
Change-Id: Iaf90c20c330e0470b9b98627a0228cadefd301d1
Adds a method for getting watchlist's notification timestamps
for a batch of LinkTargets.
Bug: T129482
Change-Id: I1f84212e7879a84b34bb3b53859069fcea282bba
The problem is that ApiQuery requires the 'read' right even though
ApiQueryTokens doesn't.
So, we introduce an exception: if action=query gets only meta=tokens
(and optionally rawcontinue and indexpageids, since they don't affect
anything), no other modules and nothing in the ApiPageSet,
ApiQuery::isReadMode() will return false.
Bug: T130112
Change-Id: I83dafb0305ff0cb1fc3bac668b88b5d2022e5880
Half of the work needed for handling this logging stream was done using
the channel name "ApiRequest" and the other half was done under the name
"ApiAction". The ApiRequest naming is easier to change at this point.
Bug: T108618
Change-Id: I5797731abeba22ef6ced7c8407ee670344d35b3d
This is for batch counting of visiting watchers, following the change
made in I2868c31fc09121de381d822e8f49194e3022bb42.
Query/logic has been extracted from ApiQueryInfo.
Bug: T129482
Change-Id: Ia9a534f5edb7af3cb7bf86be358dddb5d8c259cf
Ie84e6feaa42db1bc7a1f89b56aed37dd7fe95ea4 part of them problem
with incorrect API response but if when no watchers data is
fetched (ie. due to early return in ApiQueryInfo::getWatcherInfo),
response contains "watchers": null instead of skipping "watchers"
key entirely.
Bug: T129482
Change-Id: I9cab120ec4e6a9cf4626678e45ef14ea8efc8cbc
Fixes an issue introduced in:
I5a465773599cce9f8c9e94847cede6d12282c827
The new code now returns all targets even when 0
watcher have been found.
This patch adjusts the api to expect that.
Bug: T129482
Change-Id: Ie84e6feaa42db1bc7a1f89b56aed37dd7fe95ea4
This query / logic has been extracted from
ApiQueryUserInfo.
Unit & Integration tests have also been added.
Relating to the task linked this is the last change
needed in this ApiQueryUserInfo!
Bug: T129482
Change-Id: I91aa109416c16cd1f257c9de46669e35d6fd34d7
* ApiBase::addTokenProperties() was removed (deprecated since 1.24).
* ApiBase::getFinalPossibleErrors() was removed (deprecated since 1.24).
* ApiBase::getFinalResultProperties() was removed (deprecated since 1.24).
* ApiBase::getRequireAtLeastOneParameterErrorMessages() was removed (deprecated since 1.24).
* ApiBase::getPossibleErrors() was removed (deprecated since 1.24).
* ApiBase::getRequireMaxOneParameterErrorMessages() was removed (deprecated since 1.24).
* ApiBase::getRequireOnlyOneParameterErrorMessages() was removed (deprecated since 1.24).
* ApiBase::getResultProperties() was removed (deprecated since 1.24).
* ApiBase::getTitleOrPageIdErrorMessage() was removed (deprecated since 1.24).
* ApiBase::parseErrors() was removed (deprecated since 1.24).
* Remove related constants ApiBase::PROP_ROOT, ApiBase::PROP_LIST,
ApiBase::PROP_TYPE, ApiBase::PROP_NULLABLE.
Patches were submitted for remaining uses in Gerrit extensions.
Change-Id: Idea70300874258fbcb9deef6504eb55f2ebe8d6c
No more uses found in core or Gerrit extensions for the following methods:
* ApiQuery::getGenerators() was removed (deprecated since 1.21).
* ApiQuery::getModuleType() was removed (deprecated since 1.21).
* ApiQuery::setGeneratorContinue() was removed (deprecated since 1.24).
Change-Id: I1d46adc9ecad598c7d7726a2243bba4f7a04531a
This also removes assumptions that when a page
in one Namespace should be watched / removed
that the page in the talk / subject ns for the
page should have the same action applied
This should maintain all backward compatability
for the WatchedItem class
This also includes tests written by:
- WMDE-leszek
- Addshore
Bug: T127956
Change-Id: Iad9abafe4417bb479151a3bfbee6e1c78a3afe3c
- Add 'tags' parameters to appropriate API modules
- Add tag-adding logic to appropriate functions that carry out
relevant functions
- ManualLogEntry::{set,get}Tags to handle adding tags to log
entries in a cleaner fashion
- Use ManualLogEntry::setTags in LocalFile::recordUpload2
Bug: T97720
Change-Id: I98c52da7985623bfdafda2dc2dae937b39b72419
I searched for /\$(\S+) = (.+?\(.*?\);)\n.*?\$\1\[/, ignored
everything involving isset(), unset() or array assigments, then
skimmed through the remaining results and changed things where they
made sense. These changes were not automated, so please review them.
Change-Id: Ib37b4c66fc57648470f151ad412210b3629c2538
In addition to the 5 attempts every 5 minutes rule, add some long
term rules. Its extraordinarily unlikely that a non-malicious person would
use the wrong password 150 times in a row, so add a rule that you
can't have 150 login fails in a row in 48 hours all from the same
IP address. Also add the ability to set throttles across all IPs, but
do not set any of these types by default (There is an unclear risk/benefit
tradeoff between making it easy to lock someone out of their
account in a DoS attack, and preventing brute-forcing)
Bug: T122164
Change-Id: I5c279906936ef3991a42fc21325c3ffd4a200493
This function was added in PHP 5.4.0 and can be used now that MediaWiki
only works with PHP 5.5.9 or higher.
Also fixed a bug in ApiQueryCategoryMembers::validateHexSortkey() that
allowed a single line feed at the end of the string to pass.
Change-Id: I5b577e7dcc5fb6a06ab550429aae657dbcc79083
