Mediawiki-api

mediawiki-api@lists.wikimedia.org

1 participants
1265 discussions

Cross-domain AJAX problems with Wikipedia's API
by Kristian Kankainen 05 Sep '14

05 Sep '14

Hello! Since I don't get even the simplest code snippet to work (e.g [1]) I want to ask a really simple question. Am I allowed to query the Wikipedia API [2] from any domain if I specify the 'origin' field to correspond my domain? Or is there a whitelist with only perhaps all relevant WikiMedia sites blocking me from this. I have tried more elaborate ajax script parameters following all bot best practices but I get CORS blocked. The code snippet mentioned above was modified only with "'origin': location.origin" but I get the error: "SyntaxError: JSON.parse: unexpected end of data at line 1 column 1 of the JSON data" (using jquery 1.11.0 and Firefox 31.0). Best wishes Kristian Kankainen [1]: https://www.mediawiki.org/wiki/Manual:CORS [2]: https://et.wikipedia.org/w/api.php

4 4

[Mediawiki-api-announce] Upcoming changes to token handling (and deprecation of old methods)
by Brad Jorsch (Anomie) 26 Aug '14

26 Aug '14

I've just submitted Gerrit change 153110[1] which will overhaul the token handling in the API, as described on the API Roadmap RFC.[2] The patch is not merged yet, feel free to join in the code review or reply with comments. Follow the Gerrit change for any changes to the information below. A followup to this announcement with deployment dates will be sent once the change is merged. For clients, all the old methods of fetching tokens will continue to work with deprecation warnings. Usage levels of the deprecated methods on queries to WMF wikis will be evaluated once the MediaWiki 1.25 development cycle begins. Changes visible to clients include: * All tokens are available from the new meta=tokens query submodule. ** The "centralauth" token, which was provided by action=tokens but wasn't really a token in the sense of the rest, is now available from action=centralauthtoken. ** Note that it is possible to use meta=tokens along with other query prop, list, and meta modules. * The help for all token parameters clearly indicates which type of token is needed. * The output from action=paraminfo includes the token type as a property on the subobject describing the token parameter. * All tokens may be cached as long as the session is valid; none are dependent on factors such as the page being edited or the user being targeted. * Most token types have been replaced with a single 'csrf' token. This has long been the case in practice (e.g. see [3]), this just makes it official. * The tokens returned for action=rollback and action=userrights (and certain extension modules) are no longer the same tokens used in the corresponding features in the web UI. The web UI tokens are accepted by the API for compatibility, but not vice versa. * Any API query (with a few exceptions, mainly queries to the 'feed' modules) will return the current timestamp when passed the 'curtimestamp' parameter. This may be used to fetch the starttimestamp necessary for action=edit. For extension authors, if your extension uses the core token handling it *will* need updating. I've already submitted patches for the 26 extensions hosted in WMF's Gerrit repository. The necessary changes are: * needsToken() must return a string or false; true will result in an error. Unless there are special security issues that require a custom salt, 'csrf' should be returned. ** Since any truthy string is equivalent to the old behavior of returning boolean true, this will continue to work with older versions of MediaWiki. * If a custom salt is needed, the new 'ApiQueryTokensRegisterTypes' hook must be used to register it. * If web UI will be using a different salt (e.g. because it's included in links rather than posted form fields), a method getWebUITokenSalt() may be overridden to supply this salt for compatibility. * It is no longer necessary to return data for 'token' from getAllowedParams() or getParamDescription(). Any return from getAllowedParams() will be overridden; a string from getParamDescription() will also be overridden with a standard message, while an array will have the standard message prepended. ** Compatibility with older versions of MediaWiki may be maintained by continuing to return data for 'token' from getAllowedParams() and a string for 'token' from getParamDescription(). * getTokenSalt() is no longer called or defined in ApiBase, and may be removed once compatibility with older versions of MediaWiki is no longer needed. [1]: https://gerrit.wikimedia.org/r/#/c/153110/ [2]: https://www.mediawiki.org/wiki/Requests_for_comment/API_roadmap#Token_handl… [3]: https://en.wikipedia.org/w/api.php?format=jsonfm&action=tokens&type=block|d… -- Brad Jorsch (Anomie) Software Engineer Wikimedia Foundation _______________________________________________ Mediawiki-api-announce mailing list Mediawiki-api-announce(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce

1 1

[Mediawiki-api-announce] Deprecation of seldom-used formats, and other deprecation notes
by Brad Jorsch (Anomie) 22 Aug '14

22 Aug '14

With the merge of Gerrit change 154098,[1] various seldom-used API output formats are now deprecated: dbg, dump, txt, wddx, and yaml. Clients using any of these formats should transition to the json format. In addition, any clients still using deprecated parameters to other modules[2] should transition to the non-deprecated replacements. We've begun logging the use of these parameters on WMF wikis, and when usage drops sufficiently they may be removed. Plans are also underway to improve the json format.[2] This may result in the deprecation of format=json in favor of format=json2; if you would like to provide input on the planned changes or on whether the improved format should be "format=json2" or something else, please comment at the linked page. Thanks. [1]: https://gerrit.wikimedia.org/r/#/c/154098/ [2]: https://www.mediawiki.org/wiki/Requests_for_comment/API_roadmap#Removal_of_… [3]: https://www.mediawiki.org/wiki/Requests_for_comment/API_roadmap#Changes_to_… -- Brad Jorsch (Anomie) Software Engineer Wikimedia Foundation _______________________________________________ Mediawiki-api-announce mailing list Mediawiki-api-announce(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce

1 1

Re: [Mediawiki-api] [Wikitech-l] Bikeshedding a good name for "the api.php API"
by Brad Jorsch (Anomie) 15 Aug '14

15 Aug '14

Summing up, it seems like "action API" and "api.php" are the two contenders. "api.php" is least likely to be confused with anything (only its own entry point file). But as a name it's somewhat awkward. "action API" might be confused with the Action class and its subclasses, although that doesn't seem like a big deal. As for the rest: Just "API" is already causing confusion. Although it'll certainly continue to be used in many contexts. "MediaWiki API", "Web API", and "MediaWiki web API" are liable to be confused with the proposed REST API, which is also supposed to be web-accessible and will theoretically part of MediaWiki (even though I'd guess it's probably going to be implemented as an -oid). "MediaWiki web APIs" may well grow to encompass the api.php action API, the REST API, and maybe even stuff like Parsoid. "MediaWiki API" and "Core API" are liable to be confused with the various hooks and PHP classes used by extensions. "JSON API" wouldn't be accurate for well into the future, and would likely be confused with other JSON-returning APIs such as Parsoid and maybe REST. "Classic API" makes it sound like there's a full replacement. All the code name suggestions would be making things less clear, not more. If it had started out with a code name there would be historical inertia, but using a code name now would just be silly.

2 1

Help with runtime errors in JWBF bot?
by Frances Hocutt 14 Aug '14

14 Aug '14

I'm trying to write some basic test bots before I start writing patches for the Java Wiki Bot Framework (JWBF). I've been able to get one to compile, but I have persistent runtime errors. I've put the relevant information and things I've already tried in this gist: https://gist.github.com/fhocutt/0221c1a35265ce7cda33 Has anyone had similar problems while getting JWBF set up, or seen similar behavior from other Java projects? -Frances

1 0

Clarification on what is needed for "identifying the bot" in bot user-agent?
by Frances Hocutt 10 Aug '14

10 Aug '14

Hi all, When I wrote the new API client library standard, one of the intended effects was that libraries would make it easy for bot-runners to comply with the user-agent policy found at https://meta.wikimedia.org/wiki/User-agent_policy . However, different people understand the policy to mean different things. As I read it, the relevant parts of the policy are: "If you run a bot, please send a User-Agent header identifying the bot and supplying some way of contacting you, e.g.: `User-Agent: MyCoolTool/1.1 (http://example.com/MyCoolTool/; MyCoolTool(a)example.com) BasedOnSuperLib/1.4`" There's been some discussion in the context of my client library evaluation project here: https://www.mediawiki.org/wiki/API_talk:Client_code/Evaluations/Java_Wiki_B… and here: https://github.com/jpatokal/mediawiki-gateway/issues/65 . As I understood it, the example provided demonstrated the requirements, but it's now clear to me that there's room for ambiguity in the interpretation of the user-agent policy. My question is: what information is essential to "identify" a bot? The example given appears to contain the bot name and version, a link to a page with more information and/or the repository for the bot's code, and the framework that was used to write the bot (SuperLib/1.4, I assume). Does WMF operations want all of these components? What is the minimum necessary to comply with the policy, and what is bonus information? -Frances

4 7

[Mediawiki-api-announce] BREAKING CHANGE: Removal of 'props' and 'errors' from action=paraminfo
by Brad Jorsch (Anomie) 10 Aug '14

10 Aug '14

Gerrit change 152760,[1] likely to be merged in time for 1.24wmf17,[2] will remove the 'props' and 'errors' result properties from the output of action=paraminfo. The format of the former was never clearly specified, and the latter can be extremely difficult to keep updated and will only get worse as more error handling is moved out of the API and into the underlying core code. Further detail and discussion of this change is at https://www.mediawiki.org/wiki/Requests_for_comment/API_roadmap#Removal_of_… [1]: https://gerrit.wikimedia.org/r/#/c/152760/ [2]: https://www.mediawiki.org/wiki/MediaWiki_1.24/Roadmap -- Brad Jorsch (Anomie) Software Engineer Wikimedia Foundation _______________________________________________ Mediawiki-api-announce mailing list Mediawiki-api-announce(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce

2 1

Re: [Mediawiki-api] [Wikitech-l] Bikeshedding a good name for "the api.php API"
by Amir Ladsgroup 07 Aug '14

07 Aug '14

UnicornPI (unicorn-pie) sounds good to me ;) On 8/7/14, Brandon Harris <bharris(a)wikimedia.org> wrote: > > something something Unicorn. > > > On Aug 6, 2014, at 2:32 PM, Brad Jorsch (Anomie) <bjorsch(a)wikimedia.org> > wrote: > >> When api.php was basically the only API in MediaWiki, calling it "the API" >> worked well. But now we've got a Parsoid API, Gabriel's work on a REST >> content API, Gabriel's work on an internal storage API, and more on the >> way. So just saying "the API" is getting confusing. >> >> So let's bikeshed a reasonably short name for it that isn't something >> awful >> like "the api.php API". I'm horrible at naming. >> >> >> -- >> Brad Jorsch (Anomie) >> Software Engineer >> Wikimedia Foundation >> _______________________________________________ >> Wikitech-l mailing list >> Wikitech-l(a)lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/wikitech-l > > --- > Brandon Harris, Senior Designer, Wikimedia Foundation > > Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate > > > _______________________________________________ > Wikitech-l mailing list > Wikitech-l(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Amir

4 3

Bikeshedding a good name for "the api.php API"
by Brad Jorsch (Anomie) 06 Aug '14

06 Aug '14

When api.php was basically the only API in MediaWiki, calling it "the API" worked well. But now we've got a Parsoid API, Gabriel's work on a REST content API, Gabriel's work on an internal storage API, and more on the way. So just saying "the API" is getting confusing. So let's bikeshed a reasonably short name for it that isn't something awful like "the api.php API". I'm horrible at naming. -- Brad Jorsch (Anomie) Software Engineer Wikimedia Foundation

2 1

Bad captcha
by cook879＠shoutwiki.com 05 Aug '14

05 Aug '14

Hi guys, So I make an edit logged out and get the following back from Wikipedia: {"edit":{"captcha":{"type":"image","mime":"image/png","id":"2050100762","url":"/w/index.php?title=Special:Captcha/image&wpCaptchaId=2050100762"},"result":"Failure"}} So I use the url to try and download the image, but get nothing. Visiting the link in my browser gives Internal Error Requested bogus captcha image Any idea what’s occurring? Best regards, Richard Cook

2 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Mediawiki-api