| Nemo_bis | |
| Nov 6 2014, 8:17 AM |
| F15106: No-linkCaptcha.png | |
| Feb 19 2017, 10:42 AM |
Captcha shown on es.wiki for an edit without any URL
Tentative steps to reproduce, didn't verify:
0) Visit a wiki with 'addurl' captcha but no 'edit' captcha for you, e.g. es.wiki where autoconfirmed and hence skipcaptcha is granted only after 50 edits
I. Expected: edit is saved.
II. Observed: I'm served a captcha.
See also filter 8, which was triggered by the addition and logged+tagged the edit.
Version: unspecified
Severity: major
Attached:
A filter prevented saving those edits on es.wiki because file names were considered "possible vandalism" ("Chylus. Urina. Semen V00250 00000006.tif", for example, has too many consecutive zeros).
I think captcha worked as expected, but this filter did not.
This bug is about the captcha, which I shouldn't have seen. The AbuseFilter doesn't cause captchas, so that should be unrelated.
See also $wgTorAutoConfirmAge and $wgTorAutoConfirmCount (which *should* be unrelated, as this report already assumed I didn't have skipcaptcha).
I have made some test edits as an IP right now and I have only seen captcha when the mentioned filter has disabled my edit.
Do you remember any situation in which you saw a captcha but not a filter warning? It is possible that, if not related, this filter and the captcha have similar rules.
Doesn't the screenshot above qualify? There is a captcha, without an abusefilter warning.
But yes, it's possible that triggering an abusefilter is a requirement to reproduce this bug.
I wonder if the links table may have been outdated, and thus an earlier link addition was attributed to you :/
However IIRC it happened multiple times. I'm no longer adding images to es.wiki so I can't tell whether the issue disappeared.
@Nemo_bis can you still reproduce this problem? I tried to reproduce it locally, but I was not able to do that. Can someone probably share the AbuseFilter rule, which might be related to this?
I've not tried, as I said; and I'd need a new account since that one became autoconfirmed long ago.
I tried to reproduce it locally, but I was not able to do that. Can someone probably share the AbuseFilter rule, which might be related to this?
Ah sorry, I didn't realise the log is private. I added links to the task description. It was just a filter triggered by the string "0000000", with logging and tagging enabled. I'm not sure if the specific edit also triggered a warning; the option seems enabled since 2013.