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
