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+Int... ) 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); 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.

Thanks -Vincent _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

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+Int... ) 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

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+Int... ) 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

Ecaterina Valica wrote:

On Fri, Mar 13, 2009 at 13:04, Jerome Velociter <[email protected]> wrote:

...

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.

If you are not connected to the Internet then why do you need protection against spam bots? In an intranet the chances of being attacked are low. Just a thought ...

A secure server is not connected to the internet, but there's a proxy/firewall that passes requests to it. So, it is possible for a server to accept proxied requests from outside, but still have no external internet connection. -- Sergiu Dumitriu http://purl.org/net/sergiu/

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+Int... ) 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+applicat... 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