Vincent Massol wrote:
On Mar 13, 2009, at 8:36 AM, Jerome Velociter wrote:
Hello Devs,
I'm starting to think about the integration of JCaptcha 2.0
(
http://forge.octo.com/jcaptcha/confluence/display/general/Simple+Servlet+In…
)
that would deprecated our current Captcha plugin.
I think we need it as a component, for example xwiki-captcha
We can have a CaptchaedRequestValidator component interface that
declares the following method :
boolean validateCaptcha(HttpServletRequest request);
which would be called from the register action, comment add action,
etc.
(anywhere a captcha is needed - we could even expose a velocity API if
we need it)
WDYT ?
Hmm. Is it possible not to have it not depend on any environment
(servlet or other) or not? ie internally use the Execution Context and
any passed parameters. This is important since captcha could be used
in a variety of environments, be it portlets, servlets, maybe even web
services although that would probably be done best with a token.
Hum, the portlet
integration will have to be written if we want it. What
JCaptcha provides is a simple servlet integration, i.e:
String userCaptchaResponse = request.getParameter("jcaptcha");
boolean captchaPassed =
SimpleImageCaptchaServlet.validateResponse(request, userCaptchaResponse);
So even if we make the xwiki-captcha component API independent of any
environment, we'll have to write code that in the end is
environment-dependent in the component implementation.
We can have for example:
boolean validateCaptcha()
without any parameters and retrieve what we need in the EC, but still we'll have to
check what environment we are called from in the implementation.
So if it can be made to use the EC it's best, otherwise it should not
have request as parameter since any implementation can have the
Container object injected. If we prefer to pass a parameter (I'm still
ambivalent about this, it would be better when used in non component
env for sure) then Container can be passed. Again that's if we cannot
make it indep of the env.
Just to be sure, the public API exposed by xwiki-captcha would be
generic and not tied to any captcha implementation right?
Yes (for now the method above is all I have in mind for an API)
Jerome.
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs