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

[Michael Peters <suppressed>]

Jason A. Crome wrote:
> On Aug 25, 2005, at 11:56 AM, 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.
> 
> 
> What about those runmodes that don't need a CAPTCHA?  All of my 
> runmodes are not good candidates for it.

I'm not saying evey runmode should call create_captcha(), I'm saying
create_captcha() should be a run mode in and of itself.

>> 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.
>>
>> I you use the method I described above you don't need to store  anything.
> 
> 
> Very slick, I like that.
> 
> 
>> If create_captcha() simply returned the image to the browser then the
>> user could do something like this in their HTML
>>
>> <img src="/my/app?rm=captcha">
>>
>> And put it where ever they want.
> 
> 
> So, essentially we change the type of header produced by C::A, then 
> return the image data from the runmode?  Am I following correctly?   

Correct. The header should include the cookie information and the
content type (like 'image/gif', etc).

> If
> so, what of cgiapp_postrun?  For those of us that sometimes alter 
> headers there, this would be an issue to be contended with.

That's a good question. It's possible that a postrun could alter headers
incorrectly or mangle the image. There's a couple of options that come
to mind quickly. How good they are is definitely a wildcard :)

+ Check your get_current_rm() in postrun and don't do anything if it's
'create_captcha'. This could be a headache if you do postrun processing
in your base class (but not too bad). The biggest issue would be other
plugins trying to do something there.

+ Have a separate class that just does the CAPTCH generation. This would
of course need it's one instance script (if you use them). It would be
separate from the code using the CAPTCHA, but it shouldn't matter. But
it does seem sorta hackish

+ Maybe C::A needs a way for a plugin to not only register a callback,
but also unregister a hook/callback. So the create_captcha() run mode
would just make sure there are no postruns running. This could cause
problems though if you have postruns that need to run that wouldn't
affect the headers or the image.

More ideas welcome.

-- 
Michael Peters
Developer
Plus Three, LP


---------------------------------------------------------------------
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