We are running the Captcha module 6.x-2.1 and have the "Add Captcha Administration Links to Forms" option enabled. I am an admin and have the administer Captcha permission. None of the webforms have those links. What gives?

CommentFileSizeAuthor
#3 captcha_administration.patch591 bytesAnonymous (not verified)

Comments

soxofaan’s picture

soxofaan commented
Component: Miscellaneous » User interface

Note that, by default, CAPTCHAs (and CAPTCHA administration links) are not shown on administrative pages (pages of which the drupal path starts with "admin/").

I'm not very familiar with the webform module, so I could be wrong here:
if you're building a webform as admin, you're doing this under "admin/", if I remember correctly.
The webform from the visitor's viewpoint is at a node url like "node/123".

Are you looking at the webform at "admin/..." or at "node/123"?
You should see the CAPTCHA admin links at "node/123" (and you shouldn't see them at "admin/...").

Anonymous’s picture

Anonymous (not verified) commented
Version: 6.x-2.1 » 6.x-2.x-dev

I'll up this; Using the latest dev. I've set the permissions the right way for this to work (authenticated users have 'administer CAPTCHA ..' privileges), Manually adding a CAPTCHA to a webform does work fine, but i don't want to have my colleagues do the 'look up the form id' part by hand.

Anonymous’s picture

Anonymous (not verified) commented
Category: support » bug
Status: Active » Needs work
StatusFileSize
new captcha_administration.patch591 bytes

I actually found a solution to this, although I do think this should be considered a bug:
In order for the fieldset with the 'Add CAPTCHA to this form' link to show up, the user viewing the form has to have both 'skip CAPTCHA' and 'administer CAPTCHA settings' privileges. In my opinion one shouldn't need the skip CAPTCHA privileges.

I submitted a (very simple) patch that solves this issue. Basically, the alter_form function's innerworkings were misthought, an 'else if' was used, where an 'if' does work as (how I think it is) intended.

soxofaan’s picture

soxofaan commented
Category: bug » support
Status: Needs work » Postponed (maintainer needs more info)

I don't see how this is a bug or a solution to the original problem.
If you have a user role without the "skip CAPTCHA permission" but with the "administer CAPTCHA settings" permission, there is a bug in your permission setup. If a such a user would be faced with a CAPTCHA he could disable it anyway, so there is little point in supporting that use case.

Anonymous’s picture

Anonymous (not verified) commented
Category: support » bug
Status: Postponed (maintainer needs more info) » Needs work

Somewhere, I disagree with you, but I think the point where that is actually lies in a different problem.

I do find it a problem that users can only turn on the CAPTCHA's via that setting if they have the 'skip CAPTCHA' permission. That permission is in no way relavent in wether or not the user should be able to turn CAPTCHA's on or off for that particular form, as the user with the 'administer CAPTCHA settings' permission can turn the CAPTCHA on or off through the admin page for CAPTCHA, regardless of the 'skip CAPTCHA' permission. Therefor, I think the 'add CAPTCHA to this form' link not showing up for users with the 'administer CAPTCHA settings' permission, but without the 'skip CAPTCHA' permission is in fact a bug.

I hope you see my point. It's mostly semantics. I do agree with you that there is no point (or basically, not much, I try to be as strict as possible in permissions) in that particular user not having the 'skip' rights, it's just that it isn't documented that the user actually needs those rights in order to show the link to turn on the CAPTCHA.

soxofaan’s picture

soxofaan commented
Priority: Normal » Minor

Ok, I understand your point of "orthogonality" between the two permissions,
but I would only call it a minor bug then :) because the bug only manifests itself when there is a more important bug in the permission setup of a site (user role without "skip CAPTCHA" permission but with "admin CAPTCHA" permission).

Anyway, the patch from #3 does not work: First the CAPTCHA "widget" is added to the form with key "captcha" (e.g. $form["captcha"]) but then the CAPTCHA admin links use the same key and just overwrite that, so you'll only have the CAPTCHA admin links in the form, not the CAPTCHA widget. Or is this what you intend?

soxofaan’s picture

soxofaan commented

FYI: the issue #893810: No CAPTCHA for user login block on admin pages is slightly related to this one, or at least has overlap code-wise.

Anonymous’s picture

Anonymous (not verified) commented

I can agree on minor bug, as it is definitely workable while this bug is around, as long as you know how.
I don't agree that this bug only manifests due to a 'bad' (I honestly wouldn't call that a bug) permission setup. The bug manifests due to either lack of documentation of what the permissions do, or due to false reasoning. You basically say that any person with 'administer' permissions should also have 'skip' permissions, but it is allowed to have a setup in which the user only has 'administer' permissions.

This can be solved in multiple ways I think:
1. Clear documentation, probably at the admin page at the point where you can turn on the 'Add CAPTCHA administration links to forms'.
2. My patch. I've tried it and it seems to work the way you intend it, the user doesn't get to see the CAPTCHA, but he does get to see the administration link, without the 'skip' permission.
3. A combination of your comment on the replacement part and my solution.
4. Somehow disallow having 'admin' permissions without 'skip' permissions. (I think this one is too tough to implement though)
5. Add a new permission, just for being able to see the administration links on forms, without actually being able to administer the whole module.

I actually prefer the latter, but I won't implement it myself, as the issue has been solved here by just giving the users the skip permission.

soxofaan’s picture

soxofaan commented
Issue tags: +low-hanging fruit

Ok, I was planning a longer post, and started writing one, but given the low priority level, I shouldn't spend a lot of time on this, so I'll make it short.

What we currently have:

if (!user_access('skip CAPTCHA')) {
  // Add CAPTCHA to form if needed
}
else if (user_access('administer CAPTCHA settings') && variable_get('captcha_administration_mode', FALSE)) {
  // Add CAPTCHA administration links ...
}

What you propose:

if (!user_access('skip CAPTCHA')) {
  // Add CAPTCHA to form if needed
}
if (user_access('administer CAPTCHA settings') && variable_get('captcha_administration_mode', FALSE)) {
  // Add CAPTCHA administration links ...
}

This makes it unclear from the code what is happening in the use case we are talking about: it seems that both a CAPTCHA and CAPTCHA administration links added, but this is not true because the latter overwrites former in other parts of the code.

Therefore, I propose an alternative:

if (user_access('administer CAPTCHA settings')) {
  if (variable_get('captcha_administration_mode', FALSE)) {
    // Add CAPTCHA administration links ...
  }
}
else if (!user_access('skip CAPTCHA')) {
  // Add CAPTCHA to form if needed
}

This makes clear that the CAPTCHA admin permission has precedence over the skip CAPTCHA permission.

Anonymous’s picture

Anonymous (not verified) commented

That would be something I could totally agree on. I think this should behave as option 3 in my former post.

wundo’s picture

wundo commented
Issue summary: View changes
Status: Needs work » Closed (outdated)