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 ?

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

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