[06:38:57] Is there a way to de-link-ify red links for users who can't create the target page (or users who aren't logged in; either criterion is fine) [07:13:26] kj7rrv: it would appear as though the MobileFrontend used to have redlink removal, but that code was removed: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/MobileFrontend/+/212967/ [07:14:48] yeah. It used to be terribly annoying. [07:15:22] Oh okay [07:15:41] Why was it annoying bawolff ? [07:16:12] Because you'd be talking to someone and tell them to click a link, and they would be like "what link" [07:16:26] It was super confusing [07:16:34] especially on talk pages [07:17:45] Oh okay. [07:18:09] This would just be for logged-out users on a wiki that only logged-in users can edit, so that won't be an issue [07:23:12] kj7rrv: are you trying to do this for a private wiki (behind a firewall, etc)? [07:32:37] robla: not private, but there are a fairly small number of people with edit access [07:33:57] the reason I'm asking is because there are CSS tricks that you could do to make the redlinks not very red. [07:34:55] Yeah, but if someone accidentally clicks one, I don't want them to get a 404 [07:35:15] (that's why I want to delink them instead of just using css) [07:35:41] I guess I could use CSS and maybe some JS as a temporary fix [07:36:19] I'm not good enough with CSS to advise on this, but it wouldn't surprise me if there was a CSS property to deactivate links [07:36:40] I don't think there is [07:37:00] JS could do it, but it would be better to have it happen on the server [07:37:09] I might just write an extension for it [07:38:33] well, JS is always the nuclear option. It'd probably be fragile, but if you feel comfortable hacking up some Javascript, you could make the link text blink with whatever frequency you wanted :-) [09:45:37] is there an equivalent of $wgPasswordAttemptThrottle that does "Limit password attempts to X attempts per Y seconds per IP" instead of "Limit password attempts to X attempts per Y seconds per IP per account." [09:45:43] ideally global too [09:57:21] I would like a way to track if someone is testing various accounts and rate limit it [09:58:58] That sort of thing can be risky if you have large number of people sharing the same IP address [10:07:56] bawolff: assume we don't (or if we do it's childish kids at school who should be doing their work anyway) [10:09:30] Looks like the answer is no unless you want to add some new throttle code (You could probably mostly copy the existing code) [10:09:57] There is the allIps option, but that does per account for all ips, which is the opposite of what you want [10:10:25] Captchas can often be effective against this kind of thing, especially if it is a relatively low effort attack [10:11:38] There's allIPs ye which might help to a degree but I'd have to look at some data more [10:12:38] Also check patterns in user-agent headers. Sometimes botnet people get lazy and use a user-agent that's like chrome but 6 versions ago, which nobody else uses [10:13:36] That's a fair point [10:20:21] bawolff: chrome 90 [10:20:28] I don't see allIPs working too [10:26:31] bawolff: what hook would even work? [10:27:01] Its like an auth manager thing, so not a normal hook [10:27:59] See ThrottlePreAuthenticationProvider [10:28:36] Its registered via $wgAuthManagerConfig (or $wgAuthManagerAutoConfig ) [10:30:40] right [10:32:48] bawolff: could I just set $name to 'allusers' in https://github.com/wikimedia/mediawiki/blob/6b48e46c1ea5a2ce2e3e482993e85f6e2c583b47/includes/auth/ThrottlePreAuthenticationProvider.php#L141 [10:34:24] yeah, that sounds like it would work [10:34:52] * RhinosF1 is going to come up with numbers later [18:30:08] Is there a way to make MediaWiki (Timeless skin) work with LibreJS? [18:34:38] Does MW ship any non free JS? [18:38:55] I don't think so, but LibreJS doesn't detect a license and blocks the JS, because it doesn't know the code is free [18:43:22] Presumably because we minify and remove comments? [19:19:34] If the license isn't specified in-file (and yeah, that would be stripped anyway when minified), it's just whatever the component (skin/extension/library/whatever) is as a whole, no? [19:23:02] I will admit I am very bad at setting licenses and half my skins are likely public domain because I never bothered to touch that line, but at least in mw-land it actually is a pretty safe assumption that things are at least some kind of free as long as they're not specified not to be... [19:28:19] kj7rrv: If other skins are working with that, I'd expect it's either explicitly whitelisting them, or pulling the license from somewhere else entirely... or they've just skipped the js entirely too and you can't even tell the difference because most don't actually do much with js to begin with. If I'm wrong, though, they should show what would actually need changing, however. [19:30:12] There's a ticket somewhere for making ResourceLoader more LibreJS friendly [19:30:32] I think at the very least exposing libraries that use on Special:Version like we do for composer is a nice goal [19:54:19] https://phabricator.wikimedia.org/T38866 declined [21:42:09] Oh, so it looks like it's not going to happen? [21:45:07] Decisions can be reviewed [21:46:15] Okay [22:13:30] I don't think there's much motivation to go out of our way to be LibreJS compatible just for the sake of being compatible [22:13:31] However, I think most people are on board with ensuring we're correctly recognizing and highlighting the other projects and JS libraries we depend upon [22:16:27] unfortunately the ways LibreJS supports designating free JS are...meh at best, I'd say [22:17:18] yeah, that was my impression too the last time I looked at it [23:18:32] there is a news project [23:18:40] to fix that problem [23:18:57] check fsf news section for that [23:20:44] *news=new [23:20:53] legoktm: AntiComposite