Wither Veriword in 0.9.7?

Quote from: BobRay at Mar 14, 2008, 08:31 AM

Do I need the ob_start and/or ob_end_flush? It seems to work without them.

Only if you want to send output before initialize() is called, or need to modify the headers after sending your own output following initialize().

Quote from: OpenGeek at Apr 09, 2008, 12:52 PM

Quote from: BobRay at Mar 14, 2008, 08:31 AM

Do I need the ob_start and/or ob_end_flush? It seems to work without them.

Only if you want to send output before initialize() is called, or need to modify the headers after sending your own output following initialize().

There is output (parts of the form) sent before initialize() is called. I think the headers are modified before it hits this part of the code, though. It sounds like I might as well leave the two ob calls in just in case. They don’t seem to hurt anything.

Bob

I thought I’d bump this topic since a user just reported trouble with the Revolution CAPTCHA (although it works for me).

I have a somewhat re-factored veriword class and captcha.php that work in Revolution (though I haven’t tested in the context of the manager yet).

Some possible advantages:

1. Better reliability (I think).
2. Option for a mathstring that has the user solve a simple equation.
3. CAPTCHA words that are not in the dictionary but are easy to type and don’t contain the letters i or o.
4. Option to pass a word to use to the class.

If we’re happy with the current implementation, it’s fine with me, but I thought I’d ask in case there’s interest in mine.

I want to rip our the existing one and add yours to the "reference" extension library to show how you can easily extend the core with a custom solution like this. I don’t feel we need to have a Captcha solution in the core distribution, but I honestly have not looked into it yet to make sure the appropriate integration points are abstracted appropriately.

OK, let me get it working in the Manager and then I’ll need some help with how to package it.

Quote from: OpenGeek at Jul 31, 2008, 10:48 AM

I want to rip our the existing one and add yours to the "reference" extension library to show how you can easily extend the core with a custom solution like this. I don’t feel we need to have a Captcha solution in the core distribution, but I honestly have not looked into it yet to make sure the appropriate integration points are abstracted appropriately.

I’ve got my version working in the manager now, athough it would be a stretch to call it re-factored. I’ve just added the mathstring option and the option to send veriword your own CAPTCHA word.

I’ve looked at the possibility of taking out the current CAPTCHA and making this a package, but it doesn’t look promising. Installing the package would add 2 system setting keys (no problem, I assume), then replace login.php, captcha.php, the smarty login.tpl, and two lexicon files (or adding a new captcha lexicon file). It seems these file changes would be overwritten on upgrade.

Maybe I’m missing some authentification hook.

BTW, the current implementation is somewhat scattered. The CAPTCHA messages are in two different files and there is an "if (captcha)" conditional in both login.php and the smarty tpl file and both login.php and login.tpl contain HTML. If we don’t pull CAPTHA out of the core, at least these should be fixed.

I’m not sure what to do next.

Considering the current state of Captcha, and its moving-target status, I’d like to see it out of the core, and as a highly configurable add-on (module? plugin?)

Quote from: sottwell at Aug 09, 2008, 11:51 PM

Considering the current state of Captcha, and its moving-target status, I’d like to see it out of the core, and as a highly configurable add-on (module? plugin?)

Agreed. I could take it out completely in no time at all. The hard part is creating an add-on that puts it back without overwriting parts of the core.  

The image-generation, saving the session variable, and inserting the input field, image, and messages have to occur in the middle of the login form.  Then the validation has to occur after the submit, but only if captcha was used. Then the appropriate no-success message has to be shown whether captcha was used or not.

Quote from: BobRay at Aug 10, 2008, 02:23 AM

Agreed. I could take it out completely in no time at all. The hard part is creating an add-on that puts it back without overwriting parts of the core.

The image-generation, saving the session variable, and inserting the input field, image, and messages have to occur in the middle of the login form. Then the validation has to occur after the submit, but only if captcha was used. Then the appropriate no-success message has to be shown whether captcha was used or not.

Authentication events should easily allow the pre-rendering and post-rendering actions, and the "reference" login forms should have a hook for additional form fields to be added to the tpl dynamically. I fully expect that changes to the reference manager and many other parts of the core will need to be improved to support all the things that need to be configurable; I’ll see if I can’t pull together some core changes today to support this, as well as create a sample plugin to show how it would be done...

Quote from: OpenGeek at Aug 10, 2008, 11:28 AM

Authentication events should easily allow the pre-rendering and post-rendering actions, and the "reference" login forms should have a hook for additional form fields to be added to the tpl dynamically.  I fully expect that changes to the reference manager and many other parts of the core will need to be improved to support all the things that need to be configurable; I’ll see if I can’t pull together some core changes today to support this, as well as create a sample plugin to show how it would be done...

That will be great. While you’re at it, you might consider changing the names of some of the files. There are a number of different login.php and login.js files. The one that actually does the authentication tests might better be called something like loginproc.php.  Some comments at the beginning about who calls us and what we do wouldn’t hurt either.

Does this make sense? Pull the actual authentication tests out of loginproc.php and make it an object with a "register authentication" method that lets people register as many authentification techniques as they like, each with test code, a failure message, and a priority number (to determine what order the tests are made).

FYI, the only files I’ve modified are captcha.php and veriword.php.