In case this PR will be added to the Joomla 4 core, then we could re-use large parts of the de-DE, es-ES, fr-FR, nl-NL and pl-PL language files from:
https://github.com/pe7er/hCaptcha/tree/master/language

@richard67 Thanks for your review!
I've removed the unnecessary $spam variable + if statement.

@Fedik Should this new plugin finally use the web asset manager to load the (external) js from hCaptcha? Currently it uses the html helper.

If web asset manager: Can it be done with a future PR, too?

Test on registration page:

Same problem non contact form:

@richard67 it better if it will be done initialy, but can be another pull of course

There nothing complicated:

$this->app->getDocument()->getWebAssetManager()
  ->registerAndUseScript('plg_captcha_hcaptcha.api', 'https://hcaptcha.com/1/api.js', [], ['defer' => true]);

Good!

Also tested in contact form

I have tested this item ✅ successfully on 3a84ac0

I've changed filter="string" to validate="options" and removed an unnecessary parameter description. Thanks @Quy !

@richard67 it better if it will be done initialy, but can be another pull of course

There nothing complicated:

$this->app->getDocument()->getWebAssetManager()
  ->registerAndUseScript('plg_captcha_hcaptcha.api', 'https://hcaptcha.com/1/api.js', [], ['defer' => true]);

@pe7er Could you check @Fedik 's suggestion, too? Would be nice to have it in the new J4 way initially.

I've changed the HTMLHelper for getWebAssetManager to include the external JavaScript
Thanks @richard67 & @Fedik

@Razzo1987 Could you repeat your test as soon as you can find some time? There have been some final changes meanwhile in this Pull Request. Thanks in advance.

Add to installation scripts to remove having to discover.
Add update scripts.

I'm testing with:

• Theme: dark
• Size: compact
  

Is not compact, is square XD

On contact form:

• Theme: dark
• Size: normal

Perfect!

I have tested this item ✅ successfully on 4580380

Work! I'm not a robot 😄

I have tested this item ✅ successfully on 4580380

I confirm

before

after

Add to installation scripts to remove having to discover.
Add update scripts.

@pe7er Let me know if I shall help with the SQL stuff. The SQL stuff is required in my opinion.

I've made the changes that @Quy + @SharkyKZ recommended.

I've made the changes that @Quy + @SharkyKZ recommended.

@pe7er Except of Quy's request for installation and update SQL.

@richard67 Do you mean the SQL installation stuff in
installation/sql/mysql/base.sql
installation/sql/postgresql/base.sql

@richard67 Do you mean the SQL installation stuff in
installation/sql/mysql/base.sql
installation/sql/postgresql/base.sql

@pe7er These it needs for new installation, insert into extensions table. In addition it needs for updating for each database type a new update sql, e.g. 4.0.0-2020-04-28.sql, with the same insert statement for the extensions table. You could look it up by searching for such inserts in present update sql scripts and copy from the latest one.

I've added the installation and update SQL
Thanks @richard67 + @Quy

Fixed the error messages with the new language prefix: PLG_CAPTCHA_HCAPTCHA

Will this not conflict with https://extensions.joomla.org/extension/access-a-security/hcaptcha?

E.g if:

• A user has a Joomla 3 site
• Installs this extension from JED
• Updates to J4

Good point!
I use the same code base + naming for this J4 version and that other J3 version.
I suppose that it depends on how the pre-update checker in Joomla 3.10 will work.

Please fix conflicts.

@Quy I've solved the merge conflicts in the base.sql of mysql and of postgresql.

I use the same code base + naming for this J4 version and that other J3 version.
I suppose that it depends on how the pre-update checker in Joomla 3.10 will work.

What kind of things would you expect that pre-update checker does? We have to use a different name for the version in core else it is going to get conflicted with yours from the JED. This is the same I did for my lazyloading and my httpheaders plugin just because of that upgrade conflict.

Thanks @zero-24

• I've replaced file_get_contents with HttpFactory,
• added some checks on response + $verifyResponse (which are also in this J3 version https://github.com/pe7er/hCaptcha )
• solved a deprecated warning

@Razzo1987 @adj9 Could you test again with the latest changes? Thanks in advance.

Testing fail:

Error

Invalid response from hcaptcha.com

Invalid field: Captcha

I can confirm @Razzo1987 's finding, and unfortunately there is nothing in PHP error log.

The message is shown in an alert after the captcha challenges have been solved, the "I'm not a robot" got a green check mark and then submitting the email.

@pe7er Could you check the review comment above and the corresponding report of the failed tests? I'd really like to see this fixed and tested and merged.

Thank you @Razzo1987, I can reproduce your issue.

@richard67 I've tested @SharkyKZ improvement (Thanks!) and added it to this PR.

@pe7er Will test tomorrow. Thanks @SharkyKZ 👍 .

I have tested this item ✅ successfully on 9528f0a

@Razzo1987 Hi Luca, could you test it one more time? I think it's good now. Thanks in advance.

Drone failure seems not to be related to this PR.

Thanks for your two small fixes (language file + xml manifest) @Quy !

Add back RTC because last change was only language string changes and the removal of not existing installation script from the manifest XML.

Is there a reason this was not merged 4 months ago?

@richard67 can you have a lock at the conflicts

@rdeutz It needs not only to fix the conflicts, it also needs to rename the schema update SQL scripts to they run when updating a previous 4.0 to the version which includes this PR, and it needs to adapt these SQL scripts to changes which have happened meanwhile in the core for the extensions table, e.g. the custom_datacolumn which has been added back and needs to provided with a value (empty string) in the insert statement. So that's a bit more work. Not sure yet if I have a push permission to Peter's branch.

I've renamed and adjusted the update SQL script. Now I will fix the conflicts in the base.sql. Please be patient, it is not trivial.

@rdeutz Conflicts solved. Now let's wait if the system test pass, then we know the base.sql scripts are ok. Theoretically it would need new tests for update to see if my changes in the update SQL are right.

I've chosen yesterday's date for the update SQL because today's date is already used in one of my current PR's.

Drone failed in unit tests, very likely just the randomly ocurring timeout. Restarted drone.

@rdeutz Drone passed. All done.

The RTC label has been removed.
What has to be done to get it to RTC (or preferably merged if the code is ok) again?

The RTC label has been removed.

No idea. Maybe by accident? But the bot has added it back now, it seems. @alikon Any idea what happened?

from #28798 (comment)

Theoretically it would need new tests for update to see if my changes in the update SQL are right.

Back to pending.

I'll try to find testers on weekend and try to find time for testing myself. Thanks all for being so patient.

I have tested this item ✅ successfully on 773295f

I have tested this item ✅ successfully on 773295f

Work, without any problems
Tested with Mac OSX, Chrome 86.0.42.xx

RTC

@wilsonge Please decide if you want to have this in 4.0. If you asked me, I would say: Yes.

Once the decision is made this should be added here too: https://github.com/joomla/joomla-cms/blob/4.0-dev/libraries/src/Extension/ExtensionHelper.php#L176 ;)

Once the decision is made this should be added here too: https://github.com/joomla/joomla-cms/blob/4.0-dev/libraries/src/Extension/ExtensionHelper.php#L176 ;)

That should be made even before. @pe7er Can you do that? If not let me know and I'll do it for you in this PR here.

So my personal opinion on this is that we don't need this in core - and it can just be a 3rd party plugin - I don't see that need in core. In terms of the cloudflare original we know that the criteria is one million queries per month (or 1,000 API calls per second) - I highly doubt there are that many Joomla sites that are close to that level of traffic.

I understand that some people feel sketchy about using Google products for whatever privacy reasons they have. But I think that's still probably the minority case.

Maybe I'd have a different decision if we were implementing the first captcha plugin for the core default. But I don't really see any need to change out an existing working implementation on either of the grounds above.

Thanks for a making a decision on this.
No problem! I'll release it as a free non-core plugin instead.

I would really like to see this in Joomla 5. Especially as the feeling against the google options seems to be growing even stronger

Thanks, I understand the decision to not add it.
I've already released it as a free plugin 3 years ago (for J3 and J4) :
https://extensions.joomla.org/extension/hcaptcha/

I think the reasons then are less valid now

As hcaptcha is also located in US, it is also not GDPR compliant because is transferred to US. So using hcaptcha also requires a consent by the user in the EU. But in opposite to Google they at least tell in their privacy statement they collect, process and provide to 3rd parties (among which there are again US companies).

That's not a reason to not include it

That's not a reason to not include it

Right. But its an information which could be relevant when making a decision.

My personal opinion is that if we include a 3rd party captcha plugin from Google, we can also include the hCaptcha, as that seems to be a big more privacy friendly than the Google one. Another way could be not to include any captcha at all in the core. So I would be ok with the hCaptcha but that's just my opinion as a user.

In some eu country hcaptcha isnt compilant for gdrp did you see me open discussion ? Maybe an honeypot Can be good for starting

The past showed us that the core should not have any reference to a 3rd party service. One of the biggest issues we face is when they do some updates. It is really hard for us to follow because of the backwards compatibility problems. The core should offer an easy integration, but not deliver the implementation for externals services at the same time.

@laoneo that's a reason to never use any code that we haven't written ourselves which is a NIH policy we abandoned about ten years ago.
Do I really have to list all the external 3rd party services that are included in core.
TinyMCE
Codemirror
Bootstrap
Fontawesome
Jquery
skipto
sa11y
...

I think I have to explain you first the difference between a service and a dependency. A dependency is something we deliver with the installable package which is not maintained by us. At the time we ship it, there is no license issue and it doesn't call any external web site. So when we ship bootstrap in core and bootstrap.org is down or when they change their license it doesn't affect the CMS. We do not call any of their websites during productive mode, so there is no privacy issue at all.

With services it is completely different. Services do call external web sites while using in production mode. Does a service go down, change their license or removes a API endpoint we are using, then the CMS is broken. I do experience the same at the moment where zoom did break a deprecated API 4 months before it ends from one day to another. The worst use case I can think of is when a service is changing their license and the CMS has to pay per installation.

So there is a huge difference between a service and and a dependency. What the core should provide is an easy API that extension developers can integrate external services easily into core. But the core itself should not call any other website except the current one.

Then you should have already removed all existing 3rd party services

#39662

@micker thanks for the link.