[02:47:15] Is there a way to permanently delete a revision from a wiki, going beyond Oversight? [03:00:09] Not easily [05:24:18] What exactly would happen if someone ran `DELETE FROM revision WHERE rev_id = $targetRev`? Would things break? The actual text content of the revision would still exist, but page history, user contribs, etc. wouldn't be able to find it [05:31:37] db errors on the history, etc. pages [05:32:37] why would there be an error? The queries to get edits to a page just wouldn't see anything [05:32:52] though I guess recent changes and log entries associated with revisions would have problems [07:13:08] Is there a way to generate OAuth credentials via the command line? [07:13:17] I see OAuth extension has maintenance/createOAuthConsumer.php but this only creates consumer_key and consumer_token [07:13:48] Any way to get an access_token and access_secret as well? [08:32:41] Hi, is there a way to have some sort of string similarity function available for Abuse Filter? [08:33:50] A LTA has been cretaing pages which looks very similar to , and after normalisation, de-capitalisation, Dice's Coefficient is giving > 0.9. [08:45:42] I would have to create a bot to stop the LTA, which could easily be stopped if there is a string similarity in pace. [12:46:26] Hello? How can the user group "user" only upload files but not edit? [12:52:20] So... No one? [12:53:00] LClightcat: please be patient [12:53:09] Do you mean reupload the image? [12:53:41] No, it is uploading a new picture. [12:55:05] LClightcat: uploading a new image over one already uploaded should be possible for 'user' [12:55:16] https://github.com/wikimedia/mediawiki/blob/master/includes/DefaultSettings.php#L5578 [12:55:45] Weirdly not reupload-own though [12:56:03] But if I disable the "edit" permission, the user will not be able to upload. [12:56:04] OK [12:56:04] Oh ye they can [12:56:32] Ok thank you very much [12:57:06] LClightcat: edit should affect upload [12:57:18] Yeah.... [12:57:39] So I am going to prohibit the creation of new pages. [12:58:33] Ok [12:58:40] All in all, thank you! [12:59:20] You'll probably need both edit and page creation rights to upload, since it does create a new file page. [12:59:51] Oh..... [13:00:55] Let me think of another way. Of course, thank you! [13:02:42] Hi. An user just contacted me an informed me that he is unable to submitc changes anonymously on mobile. The text "enter confirmation code’ appears, no CAPTCHA. Am Using reCAPTCHA v2 iirc [13:02:54] acagastya: there was some discussion of that in T36912 [13:02:55] T36912: Add string distance function to AbuseFilter - https://phabricator.wikimedia.org/T36912 [13:04:31] I googled for it and found it on line 41 of https://github.com/wikimedia/mediawiki-extensions-MobileFrontend/blob/master/i18n/en.json. The line reads as follows: [13:04:59] "mobile-frontend-account-create-captcha-placeholder": "Enter confirmation code", [13:05:33] Iamahuman: a JS error preventing the capthca UI from loading, presumably? [13:05:35] On the web side the CAPTCHA is invoked correctly, but it appears it is not mobile compatible with the settings I have on [13:06:40] How do I view / search / debug for the JS error? [13:06:44] also, try it on a large screen. MobileFrontend has a bunch of max-width rules for simplifying the login form. [13:06:50] Iamahuman: do they have access to developer console? [13:07:07] Just look at the browser's developer console. Usually it opens with F12. [13:07:27] I know chrome://inspect works mobile but not sure about other browsers [13:07:54] tgr_: if it's only affecting mobile they might not have keyboard with F keys on [13:08:20] So switch to mobile view, narrow window to 400px-ish and see if the reCAPTCHA is there.. [13:08:58] Might work [13:12:10] Iamahuman will disconnect, coz I'm changing network, but I can view with this irccloud account [13:12:29] Oh you're iamahuman [13:12:50] I didn't recognise you [13:16:06] The problem reproduces with any resolution, seems to be flowing from that either the Mobilefrontend and Göögël reCAPTCHA or my configuration combination ain't compatible with the Mobilefrontend. Most likely is lacking config on my part [13:16:47] Once I toggle the mobile UI on, no reCAPTCHA, just a field asking for a code. What should I do? [13:17:18] Look in js console [13:17:42] ok [13:18:05] If dev tools give an error then that's a start [13:22:28] Thanks RhinosF1|NotHere. F12 does also in Firefox produce a .js console [13:22:40] two warnings, zero errors [13:22:57] and the warnings are challenging to copy-paste [13:24:19] "Wrong code, try again" the field briefly says when I leave it empty and hit "save" [13:36:38] I located that string also in the mobilefrontend .json and I stand by my original thought that either Mobilefronend is not compatible with the Extension:ConfirmEdit's implementation of Google reCAPTCHA or I just haven't conffed something right [13:37:29] back to the search engine.. [13:43:07] back from the search engine.. This seems to be an issue also others are struggling with: Only few types of CAPTCHAs can be used when using MobileFrontend https://www.mediawiki.org/wiki/Topic:Uk1vm2ln781c0jat [13:43:56] So the question is... Can I conf a different type of captcha being invoked based on if the user is in mobile UI or web UI ? [13:47:28] I'm not entirely sure but if mobile exposes whether it's active then yes [13:49:00] You could check one of its hooks [13:49:09] But might be a simpler way [13:49:27] Hi LClightcat [13:54:22] Hi [13:59:24] Let us know if you need more help LClightcat [13:59:34] tgr_: Okay, looking... [14:00:54] tgr_: this LTA had been creating titles (not much content in the article body). [14:01:25] I calculated dice coffecient for the title against the . [14:02:07] And now, I am trying to check hamming distance to weed out false positives. [14:02:21] Ok, so anyone have any ideas how I could make it so that mobile and web users are served a different CAPTCHA, coz the Google reCAPTCHA NoCaptcha does not seem compatible with Mobile Frontend or vice versa ? [14:02:25] But this is a bot-based block, and a filter would be much better. [14:02:32] No, I don't. thank you! [14:20:49] acagastya: I suppose for titles it could work [14:21:02] you should file a Phabricator task [14:21:16] it won't help in the short term though [14:24:02] Short-term is a bot solution. [14:24:14] Iamahuman: are you using ConfirmEdit? [14:24:27] However, I don't know how an emergency shutdown button can be used for botpasswords. [14:28:38] tgr_: Yes, I am [14:29:06] and the reCAPTCHA invisible captcha does not work for my mobile users [14:30:35] is it a public wiki? [14:30:40] yes [14:31:12] acagastya: the shutdown button is just a link to blocking like on enwiki, I presume? [14:31:27] blocking hasn't got anything to do with the bot's login method [14:31:45] Iamahuman: can you share a link? [14:31:49] tgr_: https://develop.consumerium.org/wiki/Main_Page [14:33:07] Iamahuman: you need to update first [14:33:17] oh, you are using ConfirmAccount? [14:33:24] Huh, 1.35.1 not the latest? [14:33:30] tgr_: can we block 'Example@myBot' created using Special:BotPasswords, without blocking user:Example? [14:33:39] Iamahuman: see your PM [14:35:22] acagastya: no, those are just login methods, not separate accounts. Others won't even be able to tel whether an edit was done via bot password or not. [14:36:18] tgr_: Using ConfirmAccount and ConfirmEdit ... hordes of bots hit in 2008 and 2010 [14:37:07] Sigh. [14:40:04] Iamahuman: oh, sorry, I thought the problem was during signup. I see now you were talking about editing. [14:40:32] That's pretty hopeless, MobileFrontend replaces the edit interface entirely. [14:43:16] I suppose you can intentionally break MobileFrontend's routing [14:43:38] something like https://develop.consumerium.org/w/index.php?title=Research/US/How_to_find_out_who_owns_what&action=edit#/xxx won't get hijacked because there already is a route [14:43:55] so maybe you can add that to edit links somehow [14:44:07] or maybe there's a proper way to disable the edit overlay in MF [14:46:45] tgr_: I don't quite understand it, but that link you posted, in a non-logged-in browser, does show the reCAPTCHA, whereas normally it doesn't show up [14:47:01] in the mobile view [14:47:35] yeah because it has a fake route, which prevents the MobileFrontend logic from rerouting it to the mobile edit form [14:48:22] another trick would be to create an edit link with action=submit instead of action=edit [14:52:11] rather no tricks, but a reliable documented way of circumnavigating this problem [14:53:58] At least now I know of this problem, previously I had no idea of this existing. Hopefully someone fixes it. It would seem to me (but not sure) that the Mobile Frontend should somehow be different so that the CAPTCHA would be displayed as it is to web users [16:00:55] Iamahuman: MobileFrontend implements its own edit form. It would have to implement its own captcha handling too. Or rather, provide a hook point (maybe it does that already) for ConfirmEdit to implement. [16:01:07] Feel free to file a bug etc. [17:47:18] [18:00] Iamahuman: MobileFrontend implements its own edit form. It would have to implement its own captcha handling too. Or rather, provide a hook point (maybe it does that already) for ConfirmEdit to implement. [17:49:33] but that is all I know about this issue, kinda hard to file a bug when not very much understanding what it is about. Maybe I just explain the situation in laymans terms and refer that in irc they suggested that MobileFrontend "to provide a hook point" and the people behing ConfirmEdit "implement hook"