25 May
2018
25 May
'18
12:37 a.m.
Hi,
On 05/24/2018 05:15 PM, Eduard Moraru wrote:
Question:
Do we need the captcha module to function without the DB as well?
This would make it more difficult to create the configuration UI (in
Administration) and would also mean that some captchas implementations
might not respect this constraint (i.e. choosing to implement their UI in a
wiki page instead).
IMO, it's not really worth the trouble and we should proceed to extending
the current captcha module into 2 parts: -api and -ui (the current module
would be converted from "jar" to "pom" and the current code will be
deprecated and moved to the new -api module).
The only reason we could not to depend on the DB would be to transfer
parts of the captcha module to xwiki-commons IMO. For now, I don't see
any particular use case that could support this migration.
Thanks,
Eduard
On Tue, May 22, 2018 at 8:35 PM, Eduard Moraru <enygma2002(a)gmail.com> wrote:
> Hi, devs,
>
> XWiki's current CAPTCHA module [1] is very old and outdated for a while
> now and this is not news for anyone.
>
> I see 2 major problems:
> 1) The obvious one is that we just need a technologically better CAPTCHA
> implementation that the current JCaptcha-based one and JCaptcha is
> discontinued.
> 2) The current architecture is outdated as well (i.e. wrapped around
> Struts actions and initializing the VelocityContext with a custom binding)
> and hard to use (i.e. you have to write your CAPTCHA UI every time you use
> it, there is no rendering helper).
>
> For 1), as both determined a few years ago [2] and also observed from
> practice, the industry standard is now Google's reCaptcha service (either
> its v2 or invisible version, or both), so we definitely need an
> implementation that makes it easy to use in XWiki [3].
>
> For 2), we need:
> * to allow CAPTCHA implementations to provide their own rendering
> ** Can be done using a template .vm file (rendered with the
> TemplateManager), a wiki page or directly from Java code.
> ** The implementation-specific parameters could be passed to
> control/customize a particular rendering.
> ** The syntax ID may not be needed, since the only relevant output would
> be html.
> * to move to a ScriptService-based system and to leave the resource
> (image/audio) accessing concern to the individual implementation (that may
> choose to continue with Struts actions, or may choose to use something
> lighter like a REST resource or even or even something more inventive, like
> temporary attachments on some fixed page).
> * an administration UI that configures the default CAPTCHA service and its
> configuration
> * to allow callers to use a different CAPTCHA than the default configured
> one, as long as it is available (i.e. installed)
>
> Examples:
>
> = Display
> $services.captcha.display() -- default implementation, current
> configuration
> $services.captcha.recaptcha.display() -- explicitly requested
> implementation, current/default configuration
> $services.captcha.recaptcha.display({'theme' : 'dark', 'size'
:
> 'compact', 'sitekey' : 'xyz'}) -- explicitly requested
implementation and
> custom configuration overwrites
> $services.captcha.jcaptcha.display() -- other implementation,
> current/default configuration
>
> = Verification
> $services.captcha.isValid() -- default implementation, current
> configuration
> $services.captcha.recaptcha.isValid() -- explicitly requested
> implementation, current/default configuration
> $services.captcha.recaptcha.isValid({'secret' : 'xyz'}) --
explicitly
> requested implementation and custom configuration overwrites
> $services.captcha.jcaptcha.isValid() -- explicitly requested
> implementation and custom configuration overwrites
>
> Basically, the ScriptService API would be highly simplified to just
> displaying and validating, while the components would consist of 2 parts:
> * a generic Manager for the various implementations (listing,
> getting/setting the default)
> * various implementations, each responsible with rendering a form-friendly
> CAPTCHA input and using the current request for extracting the information
> they needs to read the user's answer and validate it.
>
> WDYT?
I do agree that JCaptcha is getting quite old now, however, we might
have a hard time finding new FOSS and self-hosted captcha solutions (at
least, there's not a lot of interesting artifacts on maven central [1]).
IMO, we shouldn't rely on a captcha using an external verification
service (such as Google's captchas) as we might end up blocking users
that access their wiki with a filtered / controlled internet access. One
option could be to provide a challenge which asks the user to perform a
simple math operation, or respond to a control question instead, but I'm
not convinced of the efficiency of those solutions against real
captchas. As a captcha is usually quite simple to implement (apply
operations on a text written in an image in order to make it
non-readable by OCR software), we could also support our own version,
maybe based on the generation mechanism given by JCaptcha.
Thanks,
Clément
[1] https://search.maven.org/#search%7Cga%7C1%7Ccaptcha
> Thanks,
> Eduard
>
> ----------
> [1] http://extensions.xwiki.org/xwiki/bin/view/Extension/Captcha%20Module
> [2] http://design.xwiki.org/xwiki/bin/view/Proposal/CAPTCHAinvestigation70
> [3] https://jira.xwiki.org/browse/XWIKI-12964
>