Re: [xwiki-devs] [Proposal] CAPTCHA module refactoring

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

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?