admin CAPTCHA preview, CAPTCHAs for admins, demo site CAPTCHAs

why can an untrusted user reach an admin page like admin/user/user/create in your setup?

This is not an untrusted user. But "trusted" and "does not want to see captchas anywhere" are two different things. I generally like to see the site as my users see it.

user/register only works for anonymous users and everything under admin only works for highly trusted users. Having to use a global permission (global in the sense that it applies to all forms) to get this to work properly seems like an awful waste of functionality, kind of like suggesting to disable Captcha if you don't want to see it on admin/user/user/create (slight exaggeration to make my point).

I'm surprised that you don't agree that this is broken, but if you don't want to fix it, then how about a checkbox that disables captchas (and CAPTCHA administration links) under the admin path. I bet that most admins would activate this.

That's where the CAPTCHA administration links are for.

No, I don't want to see CAPTCHA administration links unless I temporarily enable them. I want to see the site as the user see it. Think of it as "eat your own dog food."

I'm not sure I'm getting your point. But what's wrong with one global "skip CAPTCHA" permission? Are you suggesting that there should be more granularity so that you can enable/disable CAPTCHAs for each possible combination of roles and form_id's?

No, the global permission is fine. You suggested to use it for getting rid of the CAPTCHA on admin/user/user/create. IOW, if I want to fix admin/user/user/create I should set "skip CAPTCHA". Committing the permission to fixing admin/user/user/create means I can't use it anymore for what it was intended for. IOW, using the global permission is not a valid solution to the local problem on admin/user/user/create. Disabling ALL captchas is not the solution to getting rid of just one, because I'd like to continue seeing the others.

I think our communication problem is that for you "untrusted" and "see captchas" are equivalent:

untrusted => see captchas
see captchas => untrusted

For me it's more like:

untrusted => see captchas (i.e. the admin want them to see captchas)
trusted => does not need to see them but may want to see them anyway (in the places where the untrusted users see them, but not on admin where untrusted users usually can't go)

'user_register' is probably one of the form_ids for which many admins want to enable a CAPTCHA. Technically, the fact that
admin/user/user/create uses the same form_id is not a bug in CAPTCHA, of course, but the effect is that CAPTCHA doesn't work as intended, which in the end is indistinguishable from a bug. So, I think the CAPTCHA module should implement a work-around for the core quirk.

On the other hand, there is this feature request #229710: Allow captchas on admin forms for adding CAPTCHAs to admin pages (in the context of demo sites) which is quite the opposite.

I thought of that and that's why I suggested to make it an option. However, demo sites with open access to admin pages are probably a small minority among the Drupal sites, and all the others would be well-served by enabling that option by default.

Have I been able to make myself clearer?

In Drupal it is very common that the look and composition of pages and forms depend on the active user role. Take the node creation form for example.

Yes, seeing more (in the sense of addtional features) is less of a problem as having a different user experience. On that very form, if you have "preview before post" enabled, this is for everyone. Not even user 1 is privileged. That's the approach that I like, and it's right there in core.

Does this also include correctly solving the CAPTCHAs? Seems very annoying to me ;)

Yes, I would like to have that possibility. Again, think of "preview before post," which I have enabled on most of my sites. Annoying maybe, but the same for everyone. I occasionally meet my users face-to-face, and it must never ever happen that someone tells me "having to click [Preview] before [Save] is annoying" and I reply "gee, I never had that problem." Or that they tell me "those CAPTCHAs are very difficult to solve" and I have to say "hmm, I wouldn't know because I never see them."

If you're letting untrusted users access admin/user/user/create, I think there is a bug in your permission setup ;)

No, no, no! Please let go of this idea! I know that it's a valid use case for demo sites and I'm not losing sight of that possibility, but this is not at all what I'm talking about. It only confuses the discussion if you keep bringing it up.

I just suggested that the user roles that have access admin/user/user/create should get the "skip CAPTCHA" permission. These users should be some sort of administrators or at least users you can trust not being spammers.

Ok, I'll accept that you recommend setting it up that way, but it would like this to be a choice. If it were set up that way, then the coincidence of the form_ids on two different paths wouldn't be a problem, but the module should work reasonably even if the admin chooses not to set that permission.

You could also show a real CAPTCHA, but then admins might think they have to solve it (which would unleash bug reports as "hey, I have the skip CAPTCHA permission, but I still get CAPTCHAs").

I agree with you. What I'm trying to say is that it should be possible to get the CAPTCHA only on user/register but not on admin/user/user/create without having to set the "skip CAPTCHA" permission.

I still don't see the bug. To me, CAPTCHA works as intended:

1. you enable a CAPTCHA on a form user_register
2. untrusted user requests form user_register
3. untrusted user has to solve CAPTCHA

What's unintended in this?

I have bots that create dummy accounts every day, and when I set user_register to get a CAPTCHA then I'm trying to solve a concrete problem. I expect the CAPTCHA to appear on user/register, but not on admin/user/user/create.

I see seven form_ids in the Challenge type per form fieldset, and I assume you've selected those seven because they are the most commonly used ones. When you selected user_register, you surely had user/register in mind, not admin/user/user/create, right? So, the CAPTCHA showing up on admin/user/user/create is unintended, right? And I think it's undesired in most cases. It's not your fault, I know, but it's nonetheless unexpected and undesired behavior of the module.

I think the page or path of a form is not important. If it has the same form_id, it's coming from the same form builder, so it's providing the same functionality in essence, so the protection regarding untrusted users should be the same.
For example with form_id user_register, the only difference between the user/register version and the admin/user/user/create version is an active/blocked option and user role checkboxes, which is not really relevant in this discussion. Both versions should have the same CAPTCHA protection.

I tend to agree, but the result of this principle is unsatisfactory in this case, IMHO. Now the question is what's the best way to fix it:

1. You suggested enabling 'skip CAPTCHA', but I'd prefer not to do that, because it removes my option to keep seeing the CAPTCHAs, and I think that's a valid use case.
2. We considered making CAPTCHA depend not only on the form_id but also on the path. I agree that this is not a good solution, because it would make everything much more complicated just to solve a special case. Maybe there are other similar cases, but I'm not aware of any.
3. We're considering implementing a new setting to disable all CAPTCHAs under admin. I think everyone would welcome and enable that setting, except those who run demo sites. And those who run demo sites are unlikely to be bothered by the CAPTCHA on admin/user/user/create. So, while this would also be global setting (similar to 'skip CAPTCHA') I don't see any use case for not wanting to enable that setting and being bothered by the CAPTCHA on admin/user/user/create. This is a valid solution IMO.
4. Finally, introduce a special-case hack for user_register, like offering two different user_register choices. This is not nice from a software development point of view, but I think user_register really is a special case: it's a form that is used in two very different contexts: #1 by anonymous users for registering (i.e. once in a lifetime) and #2 by administrators whenever they create a new user (i.e. potentially quite often, depending on how the site is managed).

#4 would fix the problem with surgical precision and avoid having to use a global option for a special case issue, but I think #3 would be desirable in a much larger context, and if we have #3, then this is a non-issue, as far as I can see.

Overall, I think we're mixing two different things in this thread:

1. as admin you want to see a real CAPTCHA like "normal" users would see it, which is a feature request. I'm however not sure this is a good idea, as it is not in line with the traditional Drupal design patterns.

I think I already have that — I just don't enable 'skip CAPTCHA'. This works fine (except for user 1, but that's ok for me) — or am I missing something?

2. you see a bug in the handling of /admin/user/user/create, which I don't see (except that the CAPTCHA admin links don't show up, but this seems not what you're aiming at).

No, it's not about the admin links. I hope I've been able to explain myself now.

I hope I have made myself clearer too
but there still seem to be some foggy clouds left in the discussion ;)

Yes, we're getting there. Thank you for your patience!

Re #6: (maybe we should have started a new thread for this, but you initiated it... :)

* if the CAPTCHA administration links option is enabled, the CAPTCHA administration fieldset is shown on all non admin/* forms

Does this mean there would be no way to get CAPTCHA administration fieldsets on admin/* forms? That would probably result in complaints from demo site administrators (who would probably want to put CAPTCHAs only on those admin/* forms that they expose).

That said, it's fine with me. Of course it will never show on user/register, because that page is only available to anonymous users (who presumably don't get the administer CAPTCHA permission). — user_register really is a special case...

* if a CAPTCHA is enabled on the form, the CAPTCHA administration fieldset is always shown (even if the CAPTCHA administration links option is disabled or even if it's on an admin/* form)

Yes, I would welcome this (but see below). If the CAPTCHA administration fieldset is compressed, it would be nice if the fieldset title could show the CAPTCHA state, so you don't have to open it to check, for example "Active CAPTCHA" vs. "CAPTCHA (disabled)".

Currently, there seems to be no way to display the CAPTCHA fieldset (for untrusted users) and the CAPTCHA administration fieldset on the same page, is there? If a user has 'administer CAPTCHA' but not 'skip CAPTCHA', the non-admin pages behave as if the user didn't have 'administer CAPTCHA'. You're making the assumption, that whoever has 'administer CAPTCHA' will also have 'skip CAPTCHA' (i.e. "trusted" <=> "skip CAPTCHA"), but that's not necessarily true.

Thinking out loud:
I think I'm unhappy with 'skip CAPTCHA' because it's mis-named. It does not just allow skipping the CAPTCHAs, but it takes the CAPTCHAs away completely, i.e. it removes something, more like 'not see CAPTCHA' (for want of a better name). Maybe there ought to be two different permissions; 'skip CAPTCHA' should allow leaving the CAPTCHA entry field empty (but still check the input if something is entered), and only 'not see CAPTCHA' would hide it.

Or even better: keep 'skip CAPTCHA' as it is, but introduce a new option that defines whether 'skip CAPTCHA' hides the CAPTCHAs or not. This would even work for user 1 (who can't not enable 'not see CAPTCHA').

It simply makes me uneasy when users see something on my sites that I don't see...

_{(sorry for delay)}

Not at all. Thank you for your extraordinary patience!

aha! ok, now I understand your use case (finally). So you have an admin user role which you don't give the skip CAPTCHA permission to on purpose, so the admin sees the CAPTCHA's like normal users.

Yes, exactly. Sorry for not making myself clear before.

Your pseudo code looks good. It would be nice if both parts could go into the same (expanded) fieldset, if they're both shown.

I'm not sure about changing "skip CAPTCHA" to something else, that's maybe food for another issue.

Ok, I've opened #291982: Make 'skip CAPTCHA' do what it says to pursue this. It would turn your pseudo code into something like

if (path != 'admin/*' || $permit_captcha_on_admin_forms) {
    if (not 'skip CAPTCHA' permission || 'see CAPTCHA' permission) {
       // add CAPTCHA if needed
    }
    if  (CAPTCHA admin permission) {
      // add CAPTCHA admin links if needed
    }
}