I also agree about this point that that we provide by default should not access anything external.
And I agree that other implementations (like google recaptcha) should be done as contrib extensions that can be installed in your wiki. Thanks -Vincent > On 25 May 2018, at 08:51, Thomas Mortagne <[email protected]> wrote: > > 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
