As some folks may recall, an action=createaccount was added to the API a
few weeks ago. Unfortunately the first pass didn't include CAPTCHA support,
so we haven't been able to use it for the live sites yet (which use
ConfirmEdit's "FancyCaptcha" mode). We expect to start using this in the
next couple weeks for the mobile Commons apps, so it's time to make it
captcha-friendly...
I've made a first stab at adding support, based on the existing captcha
interfaces for login and editing:
MediaWiki core: https://gerrit.wikimedia.org/r/53793
ConfirmEdit ext: https://gerrit.wikimedia.org/r/53794
So far I've tested it with the default 'math captcha' mode, with this test
rig: https://github.com/brion/mw-createaccount-test
If a captcha needs to be run, action=createaccount will spit back a result
including a 'captcha' field including several subfields, such as in this
example:
https://www.mediawiki.org/wiki/API_talk:Account_creation#Captcha_additions
Since account creation requires a first request to get a token anyway, this
shouldn't significantly add to the complexity of using the API.
Text captchas will have a 'question' subfield to be presented; image
captchas will have a 'url' field which should be loaded as the image.
'type' and 'mime' will vary, and probably shouldn't be used too closely.
Pass back the captcha id field in 'captchaid' and the response word in
'captchaword' parameters along with the final request, and it should pass
the captcha. If the captcha doesn't pass, you get back new captcha info and
can continue.
Questions:
* Does this seem to make sense? :)
* Will other API users kill me for this or will it be easy to use?
* Any surprises that may turn up?
* Any bugs/style problems in my code so far?
-- brion
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> As some folks may recall, an action=createaccount was added to the
> API a few weeks ago. Unfortunately the first pass didn't include
> CAPTCHA support, so we haven't been able to use it for the live
> sites yet (which use ConfirmEdit's "FancyCaptcha" mode). We expect
> to start using this in the next couple weeks for the mobile Commons
> apps, so it's time to make it captcha-friendly...
>
> I've made a first stab at adding support, based on the existing
> captcha interfaces for login and editing:
Several questions:
# Will the action=createaccount be disabled by default?
# If enabled, is the action=createaccount reserved to a specific user
group?
# At first blush this appears to be designed to enable xrumer bruting.
Have you considered adding optional single-use otf image creation for
fancy captcha, which would be more cost effective on small wikis?
# There are several private modules for ConfirmEdit, as well as sites
using different captchas based on ConfirmEdit (Asirra?) How might this
interact with a site using a different (non-supported) captcha module?
Amgine
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJRQzPrAAoJEBGze5c9ley6rQcH/1GLFIZI1Z89sQsMq9qv5xlP
eCsYN6kT1JLUrl0Z5w35msvCQFePyCWJYq/QRi/V5lNKIfVoQ9K+v9fhIQ9tW2UV
BH7vcHfQCSmr4tN3RfVzjUy2uqjeoFCG4kbrm6pISHLHvc5ukZKQiJQdmwbBqwnQ
arR5pYeH7ss9Jqyt2eDzC2kcBC9Oy5XlDCUQ9oIZyTEKu5IUM4jGanSzyfd05uSx
j/hGJP4wmRSNeyV5xqNfYk1YljxjS31GjBOAGp2d7pz3+Bqan67eIugn9hPLaOQj
yuHp8clbz+mOVgBgntloJQ78cYwUk6+c0q0I9l39Anht0kCgJoK+qb4kyE/y7/0=
=ZUpf
-----END PGP SIGNATURE-----
Hi MediaWiki dev,
I want to know the revision of a HTML of an article.
I noticed that every page (no matter which namespace an article is in), the
HTML contains a section "printfooter", and there will be a url after that
looks like:
http://www.mediawiki.org/w/index.php?title=Manual:Footer&oldid=659536
The "oldid=659536" is just the revision id of the HTML of an article.
My question is, if this is a reliable way to find out the revision? Or is
there other recommended way?
Thanks
--
Jiang BIAN
This email may be confidential or privileged. If you received this
communication by mistake, please don't forward it to anyone else, please
erase all copies and attachments, and please let me know that it went to
the wrong person. Thanks.
Is there an easy way to get the parameters passed to each template
(which I can enumerate with query&prop=templates)? At present I have a
dumb state machine that counts curly braces, but I wonder if there is an
API call that will provide me with the wikitext of each parameter (keyed
by index and/or parameter name).
Hi,
I'm trying to index the full wikipedia article dump (XML) using the Lucene-search Extension.
I ran the bundled indexer scripts, and it ran for ~7 days before basically stalling about half way through.
I have read of people doing the full build in a couple of hours.
Can anyone point me towards any resources to reasons my setup might be so slow?
I'm on a fairly high-end server, so I don't think it's a hardware issue.
Thanks,
Barry
Hi mediawiki developers,
We (Google) are trying to maintain our internal mirror of
wikidata.orgup-to-date in real-time, so that our indexing pipeline can
get latest
interlanguage information in real-time.
I noticed wikidata.org is also powered by standard MediaWiki software,
where standard query api to a specific revision works, e.g.
revision query:
http://www.wikidata.org/w/api.php?action=query&prop=revisions&format=xml&rv…
and
recentchanges:
http://wikidata.org/w/api.php?action=query&list=recentchanges&format=xml&rc…
My questions are:
- Are the APIs above ("action=query&prop=revisions" and
"actioon=query&list=recentchanges") the supported way to retrieve
wikidata.org in realtime?
- Is there any document about the json format in response? It looks to
me that "links" are about interwiki/interlanguage links (or sitelinks in
wikidata.org's terminology), but I feel more comfortable if I see some
official document about this.
- There are some ids like "dewiki", "enwiki" etc, which I guess can be
interpreted to corresponding languages "de", "en" respectively. But is
there a reliable map from these *wiki to the language code? And some are
even using 3-letter prefix, e.g. gotwiki, xmfwiki.
Thanks
--
Jiang BIAN
This email may be confidential or privileged. If you received this
communication by mistake, please don't forward it to anyone else, please
erase all copies and attachments, and please let me know that it went to
the wrong person. Thanks.