Comments for "CAPTCHA"

» Submit Your Comment
Comments are only accepted during the "Proposal" phase. This proposal is currently in the "Finished" phase.
» Comments
  • Christian Weiske  [2006-08-03 05:53 UTC]

    I haven't looked at the source code yet, but it'd be nice if you would be as close as possible at the Text_CAPTCHA API. Maybe this package could be a subpackage if the Text_captcha package, being one of it's drivers that is released independently.

    Also, ogg or mp3 generation would be nice since those files take less more space and thus bandwidth to the user.
  • Mark Wiesemann  [2006-08-03 09:52 UTC]

    - I second Christian's opinion about making the API compatible to Text_Captcha.

    - There is a proposal for Captcha QuickForm element in preparation, maybe you both could work together, making the QF element being able to use both Text_ and Audio_Captcha?

    - MP3 or Ogg output would be nice.

    - You might want to use PHP License 3.01 instead of 3.0.

    - Although not stated in the Coding Standards, most PEAR uses 'echo' instead of 'print' (without parentheses).

    - Why do you extend the PEAR class? I can't see any usage of it in your code?

    - You've forgotten the constructor.
  • Tom Harwood  [2006-08-03 21:20 UTC]

    I have added the constructor, updated the license version, changed print to echo, and stopped extending PEAR, I assumed it was required in some way.

    The WAV file size generated for 5 characters is around 60kb. MP3 output is under research, but it may be be prohibitive because of the compression algorithm complexity involved; this is why initially WAV was chosen since it is universal and simple to maniuplate.

    With regards to Text_CAPTCHA, I understand your comments as two ideas:

    1) Change this proposal to Text_CAPTCHA_Driver_Audio (Text_CAPTCHA_Driver_* is required by the Text_CAPTCHA factory).

    2) Keep this proposal as Audio_CAPTCHA and change the method names so they mirror Text_CAPTCHA as closely as possible; then have a Text_CAPTCHA_Driver_Audio which delegates methods required by Text_CAPTCHA to Audio_CAPTCHA.

    I prefer #2 as gives the flexibility of requiring Text_CAPTCHA (and its dependencies, including GD lib) if you want to use it that way, or not requiring Text_CAPTCHA and using it standalone.

    Do you have any preference between #1, #2, or did you mean something else?

    Thanks for the comments :)
  • Christian Weiske  [2006-08-03 21:29 UTC]

    I would like to see #1, but if you want to stay "independent", #2 would be ok - but having it as Driver for Text_Captcha would be ideal IMO.
  • Mark Wiesemann  [2006-08-04 10:03 UTC]

    Tom, I have no real preference for #1 or #2. What I would like to see is a good integration with HTML_QuickForm_CAPTCHA, a proposal from Philippe Jausions (see This QF element could very much benefit from your audio CAPTCHA in my opinion.

    About WAV: If it's only 60 KB, that's fine. If MP3/Ogg output don't need too much time and headaches, then please also add code for that.
  • Tom Harwood  [2006-08-07 21:46 UTC]

    I have made the following changes:

    - Added full support for 8/16bit wav files of any sample rate and number of channels.
    - Added sound clips for all characters (a-zA-Z0-9#@%&_) Text_Password (thus Text_CAPTCHA) can output.
    - Updated Audio_CAPTCHA method interface to be closer to Text_CAPTCHA
    - Added example1.php
    - Updated documentation

    I have also pinged Philippe Jausions by e-mail about HTML_QuickForm_CAPTCHA :).
  • Philippe Jausions  [2006-08-07 21:55 UTC]

    Hi Tom, Got your e-mail, unfortunately I lost it (hard drive failure)...

    Anyway, I think that given the dependencies, it's probably best to have 2 separate packages, but with the driver for Text_CAPTCHA included.

    I haven't had time to look at your code yet, so I'd like to know how you handle I18N, or how easy is it for the end-user to select which set of WAV files to use, based on web browser accept-language header.

    As far as the integration with HTML_QuickForm_CAPTCHA is concerned it should be done in userland, with a callback, or group of element. The HTML_QuickForm_CAPTCHA currently regenerates the image if the user clicks on it. I can easily see a user adding Audio_CAPTCHA through pop-up, but in that case the text shouldn't be re-generated (IMO)
  • Tom Harwood  [2006-08-08 14:05 UTC]

    I was intending $_SERVER['HTTP_ACCEPT_LANGUAGE'] to be used in userland to set the directory of wavs used, ie.

    $language = $_SERVER['HTTP_ACCEPT_LANGUAGE'];
    *magic here*
    $ac->setSoundDir('path/to/wavs/' . $language);

    However I am not familiar with PEAR and I18N; should Audio_CAPTCHA handle its own I18N, or should it be left to the user?

    thanks! :)