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 <[email protected]> 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 >>
