Problem/Motivation
I want to not have captchas on my local dev site. Why is 127.0.0.1 not allowed?
Is there another (settings.php perhaps?) way to disable this module?
Steps to reproduce
Proposed resolution
Remaining tasks
User interface changes
API changes
Data model changes
Issue fork captcha-3354119
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
anybodyHi @liquidcms what do you mean by
Could you please explain:
- Expected functionality
- Current functionality
and if you know, which code or UI element you're talking about, could you please give a reference?
Thanks!
Comment #3
japerryI can reproduce the issue.. looking into it.
Comment #4
japerryFor some reason we're not allowing IPs in the reserved range. Not sure that is needed.
FILTER_FLAG_NO_RES_RANGE FILTER_VALIDATE_IP
Fails validation for the following reserved IPv4 ranges: 0.0.0.0/8, 169.254.0.0/16, 127.0.0.0/8 and 240.0.0.0/4.
Fails validation for the following reserved IPv6 ranges: ::1/128, ::/128, ::ffff:0:0/96 and fe80::/10.
These are the ranges that are marked as Reserved-By-Protocol in » RFC 6890.
Added a PR that removes the Reserved Range, but maintains the Validate IP filter.
Comment #6
anybodyThe functionality was added here: #2220275: Allow for skipping captcha based on IP Address or IP Range the reservation has already been part of the first patch and I agree, I can't see a good reason for that. To be 100% sure we could ask https://www.drupal.org/u/darrellduane for the reasons, he created the patch.
I never used it TBH.
BTW, is there any good way to write a test for this and mock the test client IP address?
I'm fine with RTBC'ing this otherwise, as the fix is simple enough.
Comment #7
japerryThere is a way to add a test, however that will involve adding test coverage to the settings form itself. While I could do that, it seems a little outside the scope of this issue.
Comment #8
anybody@liquidcms would you perhaps like to review and test it? As written above, we don't use it, but we might push things forward then.
From the code-side LGTM!
Comment #9
anybodyThanks @japerry I reviewed the issue and I think the change is correct. Never really made sense to me.
Comment #11
anybodyComment #12
anybody