On Thu, 14 Mar 2013 12:55:16 -0700, Brion Vibber bvibber@wikimedia.org wrote:
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.
Some captchas (iirc ReCaptcha) won't give you easy access to the image. And this plan won't be compatible with the variety of new captcha types like the KittenAuth-like category of CAPTCHAs. Differentiating between the types just to support text CAPTCHAs (which are really the easiest CAPTCHAs to break) also sounds unfortunate.
We might just have to do something that outputs a blob of html or a url to a html document (either perhaps as a frame url or a url to fetch the blob of html from).
On Sat, Mar 16, 2013 at 2:47 AM, Daniel Friesen daniel@nadir-seen-fire.comwrote:
On Thu, 14 Mar 2013 12:55:16 -0700, Brion Vibber bvibber@wikimedia.org wrote:
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.
Some captchas (iirc ReCaptcha) won't give you easy access to the image. And this plan won't be compatible with the variety of new captcha types like the KittenAuth-like category of CAPTCHAs. Differentiating between the types just to support text CAPTCHAs (which are really the easiest CAPTCHAs to break) also sounds unfortunate.
We might just have to do something that outputs a blob of html or a url to a html document (either perhaps as a frame url or a url to fetch the blob of html from).
Each captcha type decides what fields to return, so an implementation of KittenAuth could return a blob of HTML if it wanted. It's up to the API client to know how to handle the different captcha types for display to the user.
Brion was just describing how the existing captcha types in the ConfirmEdit extension do it.
On Sat, Mar 16, 2013 at 11:19 AM, Brad Jorsch bjorsch@wikimedia.org wrote:
so an implementation of KittenAuth could return a blob of HTML
This is the API we're talking about. It's primary purpose is to allow machine-parse-able interaction. It's probably not the best idea to return pure HTML fragments, especially if the user is requesting XML output format.
*--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
On Sat, Mar 16, 2013 at 10:48 PM, Tyler Romeo tylerromeo@gmail.com wrote:
On Sat, Mar 16, 2013 at 11:19 AM, Brad Jorsch bjorsch@wikimedia.org wrote:
so an implementation of KittenAuth could return a blob of HTML
This is the API we're talking about. It's primary purpose is to allow machine-parse-able interaction. It's probably not the best idea to return pure HTML fragments, especially if the user is requesting XML output format.
This is also a captcha we're talking about. Its primary purpose is to prevent non-human interaction.
On Sun, Mar 17, 2013 at 1:03 AM, Brad Jorsch bjorsch@wikimedia.org wrote:
This is also a captcha we're talking about. Its primary purpose is to prevent non-human interaction.
I know, but think about it this way: why would an API need to login using CAPTCHA? Because it's going to render that CAPTCHA to the user, request their login information, and then relay it to the API so that it can perform whatever actions it needs to perform.
If we return just an HTML blob, then we are enforcing that the client application show the user exactly that output. If we output machine-readable information, then the client can render the CAPTCHA however it wants.
*--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
On Mar 18, 2013 12:52 AM, "Tyler Romeo" tylerromeo@gmail.com wrote:
If we return just an HTML blob, then we are enforcing that the client application show the user exactly that output. If we output machine-readable information, then the client can render the CAPTCHA however it wants.
Which is fine, I guess? Mobile apps would want to so it their way, I guess. This will need specific code on the client to handle specific captcha types - and that is OK. Different ones do need to be handled differnetly, for optimal ux.
wikitech-l@lists.wikimedia.org