why don't you try reCAPTCHA? http://recaptcha.net/resources.html
On Fri, Mar 13, 2009 at 11:56, Jerome Velociter <[email protected]> wrote: > Vincent Massol wrote: > > On Mar 13, 2009, at 10:24 AM, Jerome Velociter wrote: > > > >> 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+Integration+documentation > >>>> ) > >>>> 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); > > > > Well this can be made indep of the environment I think. > > We could just pass an object with the data needed (the user captcha > > response and whatever other data is required) and create an instance > > of HttpServletRequest internally and pass it to jcaptcha. > > > > What am I missing (I'm sure I'm missing something ;))? > > The fact jcaptcha internally keeps a generated challenge response > alongside with the session for which it has been generated. It's the > SimpleImageCaptchaServlet itself that offers the image: > > <servlet> > <servlet-name>jcaptcha</servlet-name> > > > <servlet-class>com.octo.captcha.servlet.image.SimpleImageCaptchaServlet</servlet-class> > </servlet> > <servlet-mapping> > <servlet-name>jcaptcha</servlet-name> > <url-pattern>/jcaptcha.jpg</url-pattern> > </servlet-mapping> > > So for portlet we would have to do that same work too. In the end we can > abstract everything from the environment, but I can't see an easy way of > doing it without writing a "SimpleImageCaptchaPortlet" > > Jerome > > > > Thanks > > -Vincent > > > >> 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. > > _______________________________________________ > > devs mailing list > > [email protected] > > http://lists.xwiki.org/mailman/listinfo/devs > > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
