Jerome Velociter 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"
You are looking at a page called Simple Servlet Integration documentation. This explains how to integrate it fast with a servlet based environment. There's also http://forge.octo.com/jcaptcha/confluence/display/general/5+minutes+application+integration+tutorial that doesn't need servlets or requests at all, but it gives you a BufferedImage and you pass it a String and check that it's OK. > 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. Overall, I don't like that it defines a component. It should be plugged in transparently, like a filter. We should not call it explicitly from the rest of the code. For this, we can either: - make it a servlet filter for the moment, and register it in web.xml - add events and use the Observation module for filtering requests - start enhancing the container module so that it understands and uses filters -- Sergiu Dumitriu http://purl.org/net/sergiu/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
