Re: [cgiapp] RFC: CGI::Application::Plugin::CAPTCHA

[Tony Fraser <suppressed>]

On Thu, 2005-08-25 at 09:56, Michael Peters wrote:
> I don't think the user should have to call create_captcha() at all. It
> should be a run mode that is automatically added to the using app.
> 
> 
> > I think the above will work, but I'm not sure if I like how 
> > verify_captcha() works.

I don't see how this could work without cookies.

> This is how I would do it. In create_captcha() create a random string
> (using something like Data::Random). Then create a hash of that string
> using crypt() (and a random salt from Data::Random again). Use the
> password as the text in the image and pass the hashed value in a cookie.
> 
> If the user then submits data, verify_captcha() should look at the field
> in question, and then use crypt() again with the hashed value from the
> cookie to verify that the string would indeed match.

Using crypt() is a good start but better would be to use Digest::MD5 or
similar with a server side secret like was discussed in the
CAP::LinkIntegrety thread earlier. Also as was discussed in the
CAP::LinkIntegrety thread it might be worth including the clients IP
address in the hash.

> > I still have the following things I'm not sure about how to best 
> > implement:
> > 
> > - Image storage: I can either create the images on the filesystem, or 
> > build them in a memory-based cache (which would mean the plugin needs 
> > to add a runmode that returns an image only - doesn't sound like the 
> > best way to me).  In any case, there needs to be a good way of  cleaning
> > up old images.  Suggestions?

I'd say save the images into a web accessible directory using the
cryptographic hash as the filename. A simple "find /directory/of/images
-ctime 2 -exec rm \{} \;" scheduled to run occasionally will take care
of the old ones. Using a dynamic HTTP request just to serve 1 image
seems backwards to me especially in a CGI environment where that would
in tale a PERL interpreter startup.

I suppose as an alternate options to store the image in a memcached
using Cache::Memcached could be added to the plugin. The downside I see
to this is that you'd have to allot enough RAM to the memcached to store
at least a few hours of images.

> The only issue that could be a problem with my approach would be if some
>   or all browsers wouldn't accept cookies with an image. I can't imagine
> why they wouldn't, but I've never tested it myself.

Why use cookies at all? A hidden form variable would do just as well or
better.

I'm working on project right now that would also benefit from a CAPTCHA
plugin. I'd be more than happy to help out creating the plugin.

-- 
Tony Fraser
suppressed
Sybaspace Internet Solutions                        System Administrator
phone: (250) 246-5368                                fax: (250) 246-5398


---------------------------------------------------------------------
Web Archive:  http://www.mail-archive.com/suppressed/
              http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: suppressed
For additional commands, e-mail: suppressed