Sergiu Dumitriu wrote: > 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.
Ok. Note that this page is for JCaptcha 1.0, but there is certainly something equivalent in JCaptcha 2.0. Still we need to associate a captcha to a session ID of some sort. This is something the container-api should provide. Jerome. > >> 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 > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
