I agree that the default captcha we provide should not depend on an external service but it should just be a default. IMO the most important is to make sure it's easy to choose a different captcha implementation and we should most probably provide the Google one as an option (through a contrib extension to better follow Google captcha API evolution).
On Fri, May 25, 2018 at 12:37 AM, Clément Aubin <[email protected]> wrote: > Hi, > > On 05/24/2018 05:15 PM, Eduard Moraru wrote: >> Question: >>e >> 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 >>> -- Thomas Mortagne
