Is there a reason for keeping the two plugins as they both serve the same thing with the same keys. Can we not simply update the old Recaptcha with the code from the new NoCaptcha?
@nikosdion were we just too quick to implement?
From what I can read J-M issue is a generic issue and effected people
BEFORE the api changed and nocaptcha was introduced. Global keys are not
available anymore and haven't been since at least July. They continued to
work with the old api but do not with the new one.
From the author of the wordpress recaptcha plugin
I just released 4.1, which will copy the old public key to site_key and
private key to secret. Note that with new reCAPTCHA global key is no longer
supported. So if your site is using global key, you'll have to go to
https://www.google.com/recaptcha/admin#create to get a new key.
On 3 January 2015 at 01:27, Michael Babker notifications@github.com wrote:
Aside from this comment
#5315 (comment)
from JM, can't say I see anything that warrants separate plugins. But if
both are calling the same API endpoints anyway, then JM's issue is
something out of our hands. Unless there's a way to force the original
plugin to always use the older Recaptcha version.—
Reply to this email directly or view it on GitHub
#5595 (comment).
Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/
I think we made a mistake adding this as a new plugin especially as google only have one available captcha system for creating keys. If I was a regular user and wanted to add captcha I would chose the old one because that is labelled the same as google. (they seem to only have used the nocaptcha name as part of the announcement marketing)
As far as I understand, using the new captcha plugin OR the old one will work if a user is not using a Global key, i.e. for someone creating new keys from Google site.
Keeping the old plugin was necessary for B/C.
We should maybe consider a post installation message and dropping the old one in 4.0?
People, let’s think of it from the perspective of someone upgrading their sites. Remember that the old ReCAPTCHA library accepts existing Global keys, the new one doesn’t. So, we have two possible cases:
Keep the old plugin as-is, create a new plugin for NoCAPTCHA
The user upgrades their site and there is no observable difference. Joomla! just works and everything is fine with the world.
Replace the old plugin with the NoCAPTCHA library (optionally moving the old plugin under a different name)
Upon upgrading their site, the users realise that guests can no longer register on their site. They have no idea that the new library doesn’t accept Global keys and they are sure as heck not going to read the fine manual. They think that Joomla! 3.4 is broken.
So the best plan to move forward from a user perspective if we want to completely remove the old plugin is:
Rename the title of the old plugin to “Captcha – Old ReCAPTCHA (no longer available)”
Remove all CAPTCHA code from the old plugin, replacing it with a message “This CAPTCHA method is being retired by Google. Please use the new Captcha - ReCAPTCHA (Google’s NoCAPTCHA library)” method instead”. This way, even though the CAPTCHA method has changed, we don’t block user registrations and there’s an innocuous message which will be reported by the guests to the site owner if he doesn’t read the fine manual.
If the old ReCAPTCHA plugin is enabled, show a post-installation message asking the user to activate the “Captcha - ReCAPTCHA (Google’s NoCAPTCHA library)” plugin, stressing that Global keys are NOT accepted any more.
Obviously, rename the new plugin to “Captcha - ReCAPTCHA (Google’s NoCAPTCHA library)”
This is not an entirely problem-free solution, but there are enough hints for all but the most cognitively challenged users to figure out the obvious solution. Unless, of course, someone knows a way to positively detect global keys?=
From what I read googling the global keys no longer work on new sites with
either the old or new api. Currently they appear to be still working on
existing sites with the old api but we have no way of knowing how long that
will be true for.
I would propose either following the path Nicholas suggests OR
1. renaming the plugins as Nicholas suggests
2. Adding a message in both plugins to not use global keys and that you
should get a site key.
Existing sites will still work with no change - the only diff would be that
joomla says they are using "old reCAPTCHA"
This should mean existing sites dont break and new sites would be setup
with the new captcha.
HOWEVER we have no idea
1. how long these existing sites using a global key will work using the
global key.
2. We have no way of knowing how long the old api will work for any user
even those using a site key.
3. The captcha will not work the way that google says it will work. If they
stop users will blame joomla and / or may not notice for a long time.
Neither option is ideal but if we have to make a change (and I believe we
do) it is better to be in control of the change and the message given. So I
would prefer Nicholas suggestion
Labels |
Added:
?
|
From what I read googling the global keys no longer work on new sites with
either the old or new api.
I cannot confirm this.
Just created a new test site, used my old Global Keys with ReCaptcha and it works fine
Was that on localhost? All keys always work on localhost
On 4 January 2015 at 09:13, infograf768 notifications@github.com wrote:
From what I read googling the global keys no longer work on new sites with
either the old or new api.I cannot confirm this.
Just created a new test site, used my old Global Keys with ReCaptcha and
it works fine
This comment was created with the J!Tracker Application
https://github.com/joomla/jissues at issues.joomla.org/joomla-cms/5595
http://issues.joomla.org/tracker/joomla-cms/5595.—
Reply to this email directly or view it on GitHub
#5595 (comment).
Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/
We were wrong to call it nocaptcha. We were too fast. To avoid confusion and to ensure that NEW users use the NEW plugin I would like to propose the following.
Rename the plugins
Captcha - reCAPTCHA (Legacy)
Captcha - reCAPTCHA
The description for Captcha - reCAPTCHA (Legacy) should be changed. Add this to the beginning in bold
This legacy plugin is included for backwards compatibility. It should only be used if you are using a now discontinued "Global Site Key".
The description for Captcha - reCAPTCHA should be changed. Add this to the end
This plugin will not accept the now discontinued Global Site Key. Either create a unique site key (preferred) or use the Legacy plugin.
We probably don't need to ship the legacy plugin in new installs then. Maintain in separately like with weblinks. Note i haven't read up on this just from reading down this thread
we would still need to ship the lang files though if we want to update the
message and name
On 9 January 2015 at 16:46, George Wilson notifications@github.com wrote:
We probably don't need to ship the legacy plugin in new installs then.
Maintain in separately like with weblinks. Note i haven't read up on this
just from reading down this thread—
Reply to this email directly or view it on GitHub
#5595 (comment).
Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/
We probably don't need to ship the legacy plugin in new installs then. Maintain in separately like with weblinks. Note i haven't read up on this just from reading down this thread
I would wait 3.5 or 3.6 to do that.
Rename the plugins
Captcha - reCAPTCHA (Legacy)
Captcha - reCAPTCHAThe description for Captcha - reCAPTCHA (Legacy) should be changed. Add this to the beginning in bold
This legacy plugin is included for backwards compatibility. It should only be used if you are using a now discontinued "Global Site Key".The description for Captcha - reCAPTCHA should be changed. Add this to the end
This plugin will not accept the now discontinued Global Site Key. Either create a unique site key (preferred) or use the Legacy plugin.
Makes sense.
Ok I will make the PR thanks for checking
On 10 Jan 2015 14:06, "infograf768" notifications@github.com wrote:
We probably don't need to ship the legacy plugin in new installs then.
Maintain in separately like with weblinks. Note i haven't read up on this
just from reading down this threadI would wait 3.5 or 3.6 to do that.
Rename the plugins
Captcha - reCAPTCHA (Legacy)
Captcha - reCAPTCHAThe description for Captcha - reCAPTCHA (Legacy) should be changed. Add
this to the beginning in bold
This legacy plugin is included for backwards compatibility. It should only
be used if you are using a now discontinued "Global Site Key".The description for Captcha - reCAPTCHA should be changed. Add this to the
end
This plugin will not accept the now discontinued Global Site Key. Either
create a unique site key (preferred) or use the Legacy plugin.Makes sense.
—
Reply to this email directly or view it on GitHub
#5595 (comment).
Status | New | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2015-01-10 23:59:06 |
Closed_By | ⇒ | brianteeman |
Closed_Date | 2015-01-10 23:59:06 | ⇒ | 2015-01-10 23:59:07 |
Aside from this comment from JM, can't say I see anything that warrants separate plugins. But if both are calling the same API endpoints anyway, then JM's issue is something out of our hands. Unless there's a way to force the original plugin to always use the older Recaptcha version.