aboutsummaryrefslogtreecommitdiffstats
path: root/includes/api/ApiMain.php
Commit message (Collapse)AuthorAgeFilesLines
* API: Make uselang=user the defaultBrad Jorsch2014-11-041-3/+4
| | | | | | | | | | After consultation, it is thought that the reduced cacheability won't be an issue. This also adds "uselang=content" as an option since it's no longer the default. Change-Id: Idc24bfc8bff7392c2047a6b856760ad26a4e9800
* Fixed spacingumherirrender2014-10-301-1/+1
| | | | | | | | | - Changed spaces to tabs for indentation - space after 'function'/'if' - Added/Removed space after parenthesis/brackets/end of line - Removed space after cast Change-Id: I0e8e6a19b84b5e1308b632a0266cb78f688494ee
* API: Fix access on getExamplesMessagesBrad Jorsch2014-10-291-1/+1
| | | | | | | ApiBase declares it protected, but for some reason I had made it public in all subclasses. Change-Id: I8a50d4f47e66c7f09137968d3941dc5cdc1d28e4
* API: Include ApiMain construction in api.php try-catch blockBrad Jorsch2014-10-231-1/+2
| | | | | | | | | | | | | If the User language is accessed from ApiMain::__construct on a request via OAuth and the authorization headers weren't valid, the UsageException was not being handled. Further, the code setting $wgLang in that constructor should be using the language just set on the local context, not the main request context. Bug: 72384 Change-Id: I90900dc4a8aea22c67c0c05b38128d5dbb044f07
* API: Internationalize all remaining core API modulesBrad Jorsch2014-10-201-83/+4
| | | | | | | | | This also adds some new ApiBase::PARAM_* constants to generate more helpful help, and a method to override the default description message for the use of ApiDisabled and ApiQueryDisabled. Bug: 71638 Change-Id: Ic0c3d232e0498d58a043037e2e0c6f0b1c3edad3
* API: Clean up and internationalize pretty-printed outputBrad Jorsch2014-10-131-4/+0
| | | | | | | | | | | | | | The syntax highlighting applied to the XML format is not all that great, and applying it to other formats is just wrong. Instead of doing it ourselves, let's just add a hook and let Extension:SyntaxHighlight_GeSHi do it for us. But for that to work, we have to add RL support to the pretty-printed output, which means OutputPage. At the same time, lets internationalize the header. Bug: 65403 Change-Id: I04b1a3842abdf1fb360c54aa7164fc7cd2e50f4b
* API: Make jsonfm the default output formatBrad Jorsch2014-10-131-1/+1
| | | | | | | Now that action=help isn't requiring xmlfm for sane display, make jsonfm the default. Change-Id: I515c322f31243081ed1315a17befe9792237eeaa
* API: HTMLize and internationalize the help, add Special:ApiHelpBrad Jorsch2014-10-101-69/+152
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The existing API help, formatted as basically a plain-text document embedded in XML and with a little bolding and a few links syntax-highlighted in after the fact, works ok for experienced programmers but isn't at all newbie-friendly. Further, all the help is hard-coded in English, which isn't very friendly to non-English speakers. So let's rewrite it. The help text is now obtained from i18n messages and output in HTML, with the default display consisting of help for a single module with links to help for other modules. This, of course, necessitates deprecating many of the existing help-related methods and hooks and replacing them with new ones, but backwards compatibility is maintained for almost everything. At the same time, action=paraminfo also needs to support the 'description' and other help-related fields being output in wikitext or HTML, and I11cb063d (to access all modules via the 'modules' parameter instead of having 'modules', 'formatmodules', 'querymodules', and so on) is folded in. And we also add Special:ApiHelp. When directly accessed, it simply redirects to api.php with appropriate parameters. But it's also transcludable to allow up-to-date API help text to be included within the on-wiki documentation. Note this patch doesn't actually add i18n messages for any API modules besides ApiMain and ApiHelp. That will come in a followup patch, but for the moment the backwards-compatibility code handles them nicely. While we're messing with the documentation, we may as well add the "internal" flag requested in bug 62905 (although the 'includeinternal' parameter it also requests doesn't make much sense anymore) and a "deprecated" flag that's needed by several modules now. Bug: 30936 Bug: 38126 Bug: 42343 Bug: 45641 Bug: 62905 Bug: 63211 Change-Id: Ib14c00df06d85c2f6364d83b2b10ce34c7f513cc
* API: No mustposttoken error with $wgDebugAPIBrad Jorsch2014-09-181-4/+6
| | | | | | | | $wgDebugAPI is supposed to be a way to quickly (and insecurely) test API modules using GET where they'd normally require POST. But this purpose is defeated if token handling still throws mustposttoken. Change-Id: Iee2fb76da86bf0670f9816f24f68c611fa0728b1
* Clarify "mustposttoken" API error messageMZMcBride2014-09-101-1/+1
| | | | | Bug: 70656 Change-Id: Id30e54472299bc3998644914eca4e19e9429fd2b
* API: created a new api to flag messages as readPetr Bena2014-09-061-0/+1
| | | | | | | | | | | | | | New api is called "ClearHasMsg" and does nothing but erase a new message flag from currently logged in user. This is useful for tools that can read the new messages using some api, or some other way (loading the text using different session, preload the text using a buffer where it's unrevealed later if user actually did read it, or closed the application before), so it can be useful in situations when you need to flag new messages as read in a different time than that when you actually read them. Bug: 64238 Change-Id: Ife575711c32bb8e3bcac789de4a6b37e1888d032
* API: Overhaul token handlingBrad Jorsch2014-08-261-8/+32
| | | | | | | | | | | | | | | | | | | | The current token handling is a mess. This simplifies things greatly: * *All* tokens are obtained from action=query&meta=tokens, rather than being spread over action=tokens, action=query&prop=info, action=query&prop=revisions, action=query&prop=recentchanges, and action=query&prop=users. All these old methods are deprecated. * Similarly, there is only one hook to register new token types. All old hooks are deprecated. * All tokens are cacheable. * Most token types are dropped in favor of a 'csrf' token. They already were returning the same token anyway. * All token-using modules will document the required token type in a standard manner in action=help and are documented in machine-readable fashion in action=paraminfo. Note this will require updates to all extensions using tokens. Change-Id: I2793a3f2dd64a4bebb0b4d065e09af1e9f63fb89
* API: Add a "submodule" param typeBrad Jorsch2014-08-191-2/+2
| | | | | | | | | | | | | | This allows action=paraminfo to indicate when a parameter is specifying a submodule (so clients can detect what the submodule names are). This will also allow the future action=help HTMLization to easily auto-link to submodule docs, and will allow ApiSandbox to handle submodules more generically. For BC, rather than directly specifying "type": "submodule", it lists the names of all the submodules as the type and adds an additional "submodules" indicator on the param info object. Change-Id: Id31babdc81d970ac781ec11daa3cdafef18ecd5d
* API: Remove action=paraminfo 'props' and 'errors' result propertiesBrad Jorsch2014-08-071-18/+0
| | | | | | | | | | | | | | | | | The format for 'props' was never specified and the list for 'errors' is impossible to keep updated when considering that many errors come from MediaWiki backend code and extension hook functions. And since there doesn't seem to be any real use case for either of these, let's just kill both of them instead of wasting effort on trying to fix them. Note that neither getResultProperties nor getPossibleErrors are called from any extensions in gerrit, and none of the other deprecated methods are called outside of the implementations of those two methods. Removing the obsolete methods is left to the maintainers of the extensions, as keeping them hurts nothing and is needed to maintain compatibility with earlier versions of MediaWiki. Change-Id: Ie11a401d60c834059fbf1b5625ca8ea093b3337c
* Cleanup some docs (includes/[a-d])umherirrender2014-07-241-1/+1
| | | | | | | | | | - Swap "$variable type" to "type $variable" - Added missing types - Fixed spacing inside docs - Makes beginning of @param/@return/@var/@throws in capital - Changed some types to match the more common spelling Change-Id: I7b65fe04db431342cc58b469dc48f41a50c4e891
* Added ApiResult::NO_SIZE_CHECK flag for addValue()Yuri Astrakhan2014-07-111-5/+4
| | | | | | | | | | | | | | | | | | | This way we no longer need to disable size checking just for one operation (enable|disable)SizeCheck functions were depricated. Overall, this is a much better practice than disabling than re-enabling the flag, as it might lead to accidentally forgetting to re-enable it, just like the issue with the dangling file handlers, etc. Example: disable, do some complex logic, re-enable. And later, by accident, the complex logic is changed to return a value half-way, or throws an exception that gets handled as part of normal operations. This results in the unsafe disabled state of the result object, which is not good (tm). Change-Id: I389a334d35f52f23a1847aca4aef5e96b262f589
* Switch API to use Config classesReedy2014-06-151-30/+26
| | | | | | Only done where globals are config (so not $wgParser, $wgContLang etc) Change-Id: Ic39cdd858cfb9096a2bc09618f97e64270d76f13
* Fix broken @return documentationThiemo Mättig2014-05-241-1/+1
| | | | | | I found one of these in Wikibase and run a global search. Change-Id: I76c1519a47d7222f136272c59ea454b650808a86
* Update the API creditsMarius Hoch2014-05-131-1/+2
| | | | | | | | | | Put Brad Jorsch (anomie) as lead developer (as he's the one who does most of the review work etc. these days). Made Yuri's lead developer time frame end in 2013 (as he last commited to the api in 2013 AFAIS). Change-Id: I640ddf251340214b4520d3072e22dfe6b54815fb
* Merge "API: Warn when unsupported PHP array syntax is used"jenkins-bot2014-04-291-4/+13
|\
| * API: Warn when unsupported PHP array syntax is usedBrad Jorsch2014-04-171-4/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | The API takes multi-valued parameters as key=value1|value2|value3, not key[]=value1&key[]=value2&key[]=value3, in part because the latter is overly verbose when the API encourages use of large arrays. But when someone, not knowing this, does accidentally use the verbose syntax, they should get a warning instead of having the parameter be silently ignored. Bug: 64057 Change-Id: I32a16efb8028d7f6d120d20dfc886f08ed9ec97d
* | API: Don't rollback changes if the exception was a UsageExceptionKunal Mehta2014-04-221-1/+4
| | | | | | | | | | | | | | | | | | | | | | In I1b7396ceb, we were trying to log failures to Special:Log, but since $this->dieUsage throws an exception, the log entry insertion was being rolled back. This is similar to I36cd645d which was for index.php calls. Change-Id: I136ba66d2f939fcdd0c9326e04d686a30449bf4c Follows-Up: I8f1da51187b281fe4afc0d5a0c49f5caf3612e92
* | Fixed some @params documentation (includes/api)umherirrender2014-04-181-21/+29
|/ | | | | | | | | Swapped some "$var type" to "type $var" or added missing types before the $var. Changed some other types to match the more common spelling. Makes beginning of some text in captial. Also added some missing @param. Change-Id: I758fa4ad80ac95e2ddd3770bcb9b7d2e57ec34ea
* Merge "API: Allow for format modules that cannot handle errors"jenkins-bot2014-03-311-3/+11
|\
| * API: Allow for format modules that cannot handle errorsBrad Jorsch2014-03-271-3/+11
| | | | | | | | | | | | | | | | | | ApiFormatFeedWrapper, for example, has nothing particularly useful to do when given an API error to print. So allow for punting errors to the default formatter instead. Bug: 63150 Change-Id: Ifc034d4c7861905e382c42dc22585f0cd2beaf3f
* | Improve handling of uncommitted DB txns with "uncaught" exceptionsBrad Jorsch2014-03-271-0/+3
|/ | | | | | | | | | | | | | | | | | | | | | | One of the causes (if not the cause) of bug 56269 is if something manages to throw an exception that makes it to MediaWiki::run's last-resort exception catcher while having an open database transaction: the transaction never gets committed or rolled back, so it gets implicitly rolled back and a warning is raised. The API has the opposite problem in bug 63145: it catches the exception but then does the normal DB shutdown which *commits* the transaction. This is certainly the Wrong Thing to do. Ideally, neither of these would ever happen because any code using transactions would have its own try-catch that would catch any exception, rollback the transaction, and then rethrow the exception. But it happens anyway, so let's have both of these last-resort exception handlers do the rollback, and also log the exception so the throwing code has a better chance of being properly fixed. Bug: 56269 Bug: 63145 Change-Id: I8f1da51187b281fe4afc0d5a0c49f5caf3612e92
* Avoid header notice log spam from RunJobs APIAaron Schulz2014-03-181-1/+0
| | | | | | | | | | * Moved ApiRunJobs to a special page instead of going through ApiMain and having to fight the logic there. As a separate internal API, this does not show up on the API help page and is no longer effected by $wgEnableAPI. bug: 62233 Change-Id: I1db6f526d02e130a66ee03289858a734d89e6c00
* API: Handle exceptions from ApiBeforeMain hook in a user-friendly mannerBrad Jorsch2014-03-121-31/+68
| | | | | | | | | | | | | | | | | | | The immediate impetus behind this change is this series of events: 1. CirrusSearch hooks ApiBeforeMain to handle some setup that requires the User object. 2. So User is loaded from the session. 3. OAuth checks the headers as part of loading User. 4. OAuth sees that the headers are invalid, and since it was called from the API it throws a UsageException, expecting the API to catch it and return an appropriate response to the client. 5. But nothing does so, leading to an unhelpful "Internal Error" page being returned to the client. We can do better than that. Bug: 62312 Change-Id: Ib5735661eec6ebe57eaa69c67b399e703cc90fc4
* ChangesListSpecialPage: Separate all functionality for generating feedsBartosz Dziewoński2014-03-121-0/+1
| | | | | | | | | | | | | | | | I should have done it at the beginning instead of trying to extract it from recent changes. Same for SpecialRecentChanges and SpecialRecentChangesLinked (subclasses). Created a new API module for it: ApiFeedRecentChanges. It's somewhat un-API-like and hackish, but all feed modules are. Old URLs redirect to new ones, so this should be fully backwards-compatible assuming sane feed reader clients. Change-Id: I06ee0f01d896bc66545a1800b24693ce7524e433
* Add final period to API module descriptionsaddshore2014-03-101-3/+3
| | | | Change-Id: Icae68c1ab1fd0006e00a3a9a56ae8f831d3d0d45
* Remove API developer email addressesReedy2014-03-091-6/+5
| | | | | | | They just end up being used for direct support requests that should really be done on public mailing lists etc Change-Id: If704ec8dff5fc4669165b580290cc29cf953a25b
* Moved job running via $wgJobRunRate to a special APIAaron Schulz2014-02-271-0/+1
| | | | | | | | | | | | | | | | | | | | * A background internal HTTP request used to load the API. This handles job execution and related periodic tasks. It avoids blocking the main request or breaking it on fatals. * This method avoids problems that shelling could have: ** Mismatched apache/cli PHP config or versions. ** Had to start a new process and could not use opcode cache. ** safe_mode and open_basedir restrictions required a fallback. ** Some wiki farms may not respect the --wiki parameter. ** wgMaxShellMemory applies to spawned PHP processes. ** Spawning processes is more prone to DOS due to a lack of proper limiting/pooling. bug: 60208 bug: 60210 bug: 60698 bug: 60844 Change-Id: I78b0e709301ac4a0c7b7ed337d6969d7546674bf
* Fix CodeSniffer errors and warningsSiebrand Mazeland2014-02-051-2/+4
| | | | Change-Id: Idc74e34634d88625773fb8f73315f61edfa67e28
* Add API action=revisiondeleteBrad Jorsch2014-02-041-0/+1
| | | | | | | | Add action=revisiondelete to the API, and some functions to the revisiondelete backend to support this. Bug: 23005 Change-Id: Iee146fed648603b86a35927518f850771fc69bd2
* Enhance the destination control parameter of wfDebug() and wfDebugLog()Alexandre Emsenhuber2014-02-041-1/+1
| | | | | | | | | | | | | | | | | | | | | | | - The parameter is now a string, making is more understandable than boolean values - It takes the same values in both wfDebug() and wfDebugLog() (except for 'private' which is only used in the latter) - This adds a new possibility to wfDebugLog() to log the message either on the specific log or the general one, but not to the debug toolbar - Old boolean values are still recognised for backward compatibility - Also send the messages passed to wfDebugLog() to the debug toolbar when they are written to a specific log and not restricted to logs - Updated the calls of and wfDebug() and wfDebugLog() with the last parameter to change it into a string - Renamed MWDebug::sendWarning() to MWDebug::sendMessage() and added $group parameter to it; will not break anything since that method is marked as private - Changed the call to wfDebug() from MWDebug::sendMessage() to use wfDebugLog() with 'log' as thrid parameter, so that those messages can be logged separately from the main log and they don't show up a second time on the "debug log" tab of the debug toolbar Change-Id: I1be09d4c1d3408ed5b26a5db02691c17c0ec0926
* Merge "Remove classes and functions deprecated in MediaWiki 1.17"jenkins-bot2014-01-091-25/+0
|\
| * Remove classes and functions deprecated in MediaWiki 1.17Siebrand Mazeland2014-01-051-25/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Removed classes: - WikiError (deprecated in 1.17) - WikiXmlError (deprecated in 1.17) - WikiErrorMsg (deprecated in 1.17) Removed methods: - ApiBase::getValidNamespaces() (deprecated in 1.17) - ApiMain::setCachePrivate() (deprecated in 1.17) - ApiMain::setVaryCookie (deprecated in 1.17) - CategoryViewer::addSubcategory() (deprecated in 1.17) - WebRequest::getFileSize() (deprecated in 1.17) - WebRequest::isPathInfoBad() (deprecated in 1.17) Change-Id: Id715c2391742c136d09f5369f88d67e798842af7
* | Merge AssertEdit extension into coreKunal Mehta2014-01-061-0/+30
|/ | | | | | | | | | | | | | | | | | | | | Added &assert=user and &assert=bot for all API modules. Some functionality was dropped: * assert='exists': the edit API already has &nocreate/&createonly * nassert parameter: there is no usecase for checking that your account is logged out or not flagged * assert=true/false: If you want to test a failing assertion, log out * assert=test: Not useful * Checking edits via index.php The error format was changed from: {"edit": {"assert": "bot", "result": "Failure"}} to the standard format of API errors in an 'errors' array using the codes: 'assertuserfailed' and 'assertbotfailed'. Bug: 27841 Bug: 53106 Change-Id: Ia4815168548fea3dbf1c305792a451374f2a3b7e
* Break long lines and suppress false posiveSiebrand Mazeland2013-12-031-1/+5
| | | | Change-Id: I14c61d8060cd3a3a2a15193f6721e7f87b783538
* API: Add $wgAPIFormatModulesBrad Jorsch2013-11-271-1/+2
| | | | | | | | | | | The API currently allows for adding action modules with $wgAPIModules and query modules with various other $wgAPI*Modules variables. But there's no way to add a formatting module from an extension. For parallelism, let's add $wgAPIFormatModules to do just that. Bug: 57637 Change-Id: Ia0bd253104a4b5bc56d4fe0dc6736e2129b126f3
* Merge "Remove unneeded uses of else{} in api/"jenkins-bot2013-11-201-9/+5
|\
| * Remove unneeded uses of else{} in api/Siebrand Mazeland2013-11-181-9/+5
| | | | | | | | | | | | | | Fixed a little documentation issue, removed a line of unreachable code and fixed up two formatting issues in the process. Change-Id: If29391ee1a0daf19973437f36c3216b8716debd0
* | Format email addresses more consistentlySiebrand Mazeland2013-11-181-2/+2
|/ | | | Change-Id: I1dbced804ff1e0bf8e162570c17cc537d318872f
* Merge "Address errors and warnings in CodeSniffer in api/"jenkins-bot2013-11-181-24/+50
|\
| * Address errors and warnings in CodeSniffer in api/Siebrand Mazeland2013-11-171-24/+50
| | | | | | | | Change-Id: I06de371393d50eada33154626874b106d814642b
* | Update docs to reduce inconsistent type compatibility in api/Siebrand Mazeland2013-11-171-1/+1
|/ | | | Change-Id: Iaf97aeb514ddb2176491c3820fe891be8e989939
* Fix the fix: "? :" -> "?:"Siebrand Mazeland2013-11-141-1/+1
| | | | Change-Id: Icdbb200faf2ee5c7c6a0095987f76a2bc1b4e5e7
* Update formatting on more API classesSiebrand Mazeland2013-11-141-5/+27
| | | | Change-Id: I1e6325b628359a557ceaa1e1ae30043aa5fc1402
* exception: Use MWExceptionHandler::logException in more placesTimo Tijhof2013-10-301-7/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Most code replaced wasn't exactly like what logException does but most probably should be. A few implementation differences with the code it replaced in various places: * MWException if-guards Was there only to prevent a crash because getLogMessage is an MWException method. Now that logException is generic, it seems sensible to start logging those as well (follows-up a97f3550a0). * Exception::getTraceAsString Now using MWExceptionHandler::formatRedactedTrace instead. It wasn't using it because that method didn't exist yet. Notes: * DatabaseError::getLogMessage Removed as this override was no longer doing anything (we're using MWExceptionHandler::getLogMessage instead of $e->getLogMessage). Introduced isLoggable() to take over the responsibility of indicating when an exception should not be logged (follows-up bcb9f9e1c0d). * DeferredUpdates and Wiki.php Both specificy MWException. Though ApiMain intends to catch all and only logged MWException because it couldn't otherwise, these actually only catch MWException (as opposed to catching all and having an if-statement inside). Left those as-is to have them continue propagate other exceptions. * JobQueueFederated and JobQueueGroup All specify to catch JobQueueError only. Not sure whether it should catch other exceptions. It now can, but I'll leave it as is in case it intends to have those be handled elsewhere (or fatal). Change-Id: I4578a0fe7d95a080f1a3b292ce7ae73a4d5fcaca
* SECURITY: Prevent tokens in jsonp modeBrad Jorsch2013-09-031-8/+2
| | | | | | | | | | | | Add checks to token-returning functions to prevent returning tokens in jsonp mode. This affects action=tokens, action=login, action=createaccount, and action=query&list=deletedrevs. Also, remove the "gettoken" parameter to action=block and action=unblock, which has been deprecated since 1.20. Bug: 49090 Change-Id: Ibeaa5c72d8084585092b15935a3f5709104bf7f7
generated by cgit v1.2.3 (git 2.25.1) at 2025-04-25 09:57:58 +0000