Ecaterina Valica wrote: > why don't you try reCAPTCHA? http://recaptcha.net/resources.html
ReCAPTCHA is web-based and requires sign up. This means as pre-requisite that your wiki needs to be connected to the Internet and have the recaptcha.net site accessible + that you sign up for a key. That's already too much to be integrated in the standard XE distribution. Thought, it would be good as an installable plugin. Jerome. > > 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 _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
