catrope@svn.wikimedia.org wrote:
- Adding SimpleCaptcha::addCaptchaAPI() method that adds CAPTCHA information to an API result array. Other CAPTCHA implementations should override this method with a function that does the same (did this for FancyCaptcha and MathCaptcha)
[snip]
$resultArr['captcha']['type'] = 'simple';$resultArr['captcha']['id'] = $index;$resultArr['captcha']['question'] = $captcha['question'];
[snip]
$resultArr['captcha']['type'] = 'image';$resultArr['captcha']['id'] = $index;$resultArr['captcha']['url'] = $title->getLocalUrl( 'wpCaptchaId=' . urlencode( $index ) );
[snip]
$resultArr['captcha']['type'] = 'math';$resultArr['captcha']['id'] = $index;$resultArr['captcha']['sum'] = $sum;
Hmmm... How is an API client meant to figure out what to do with this captcha data, when there seems to be nothing consistent in how it's presented? How is it meant to display a new type of challenge which might be added in the future?
If you're going to have an API for this, I think it needs at least some minimum future-proofing; otherwise all the clients will break when something is tweaked in the captcha.
-- brion vibber (brion @ wikimedia.org)
Brion Vibber schreef:
there seems to be nothing consistent in how it's presented?
That's because all three types are fundamentally different (although Simple and Math could both have 'question'). I think we should have a general rule that anything that's text is called a 'question', and call images 'url'.
Roan Kattouw (Catrope)
Roan Kattouw wrote:
Brion Vibber schreef:
there seems to be nothing consistent in how it's presented?
That's because all three types are fundamentally different (although Simple and Math could both have 'question'). I think we should have a general rule that anything that's text is called a 'question', and call images 'url'.
There's nothing *fundamentally* different: they all present a challenge and ask for a response.
The simplest possible interface here would be to provide an HTML fragment containing the challenge; though that brings with it potential issues of safety/sanitization or HTML rendering requirements.
A second-simplest might be to provide alternatives in fixed formats -- eg, image URL or text fragment. Consider also futureproofing for audio alternatives.
-- brion vibber (brion @ wikimedia.org)
Brion Vibber schreef:
A second-simplest might be to provide alternatives in fixed formats -- eg, image URL or text fragment. Consider also futureproofing for audio alternatives.
That's what I was thinking. Audio fragments could also use the URL field.
Roan Kattouw (Catrope)
Roan Kattouw wrote:
Brion Vibber schreef:
A second-simplest might be to provide alternatives in fixed formats -- eg, image URL or text fragment. Consider also futureproofing for audio alternatives.
That's what I was thinking. Audio fragments could also use the URL field.
If so you should probably provide a type field (image/png, audio/wav, etc). Otherwise the intermediary app may not be able to guess how to present the challenge without downloading it separately first (possibly requiring a second download for the presentation).
-- brion vibber (brion @ wikimedia.org)
Brion Vibber schreef:
If so you should probably provide a type field (image/png, audio/wav, etc). Otherwise the intermediary app may not be able to guess how to present the challenge without downloading it separately first (possibly requiring a second download for the presentation).
Good idea, I added the MIME type in r31407.
Roan Kattouw (Catrope)
Brion Vibber kirjoitti:
The simplest possible interface here would be to provide an HTML fragment containing the challenge; though that brings with it potential issues of safety/sanitization or HTML rendering requirements.
No HTML in API responses, please. If I wanted to parse HTML, I'd be screen scraping the wiki interface anyway, not using the API.
URL + MIME type, plus possibly some explanatory text, should really be enough for any CAPTCHA. They're supposed to be pretty self-explanatory anyway.
One could even use "data:" URLs for short in-line CAPTHAs if one wanted.
Ilmari Karonen schreef:
URL + MIME type, plus possibly some explanatory text, should really be enough for any CAPTCHA. They're supposed to be pretty self-explanatory anyway.
One could even use "data:" URLs for short in-line CAPTHAs if one wanted.
Text responses (text/plain for SimpleCaptcha and text/tex for MathCaptcha) are currently presented using the 'question' field rather than the 'url' field.
Roan Kattouw (Catrope)
On 01/03/2008, Roan Kattouw roan.kattouw@home.nl wrote:
Ilmari Karonen schreef:
URL + MIME type, plus possibly some explanatory text, should really be enough for any CAPTCHA. They're supposed to be pretty self-explanatory anyway. One could even use "data:" URLs for short in-line CAPTHAs if one wanted.
Text responses (text/plain for SimpleCaptcha and text/tex for MathCaptcha) are currently presented using the 'question' field rather than the 'url' field.
Will putting this in for the API help at all with implementing it in the usual web interface to MediaWiki? i.e., bugs
https://bugzilla.wikimedia.org/show_bug.cgi?id=4845 https://bugzilla.wikimedia.org/show_bug.cgi?id=10340
The plaintive bug report for 10340 is well worth reading.
- d.
David Gerard schreef:
Will putting this in for the API help at all with implementing it in the usual web interface to MediaWiki?
Not in this way. Maybe we can implement some sort of mechanism that lets users choose between a visual and an audio CAPTCHA.
Roan Kattouw (Catrope)
wikitech-l@lists.wikimedia.org