[10:04:24] I did it by the way, short urls are working okay despite mediawiki running inside a container [12:59:52] does anyone know how to fix https://github.com/wikimedia/mediawiki/blob/52a6fcf9ba7a294aa22fe38bd33293509245ccce/includes/cache/LinkBatch.php#L159 [13:00:01] blocking page views [13:00:50] https://tampvan.miraheze.org/wiki/Benua_Greget & https://tampvan.miraheze.org/w/index.php?title=Perserikatan_Bangsa_Greget are affected at least [13:01:33] I'm trying to upgrade from 1.36->1.38 and things are not working. It complains about "$wgBaseDirectory must not be modified in settings files" but I never set that anywhere https://dpaste.org/6O3mc [13:04:44] https://phabricator.wikimedia.org/T300311#8011545 [13:27:57] Hi, a fresh install of mediawiki 1.38 shows some links in the wrong language (I think) -- in the page tools I see "Twa mu", "Move" and "Bɔ ho ban" instead of, respectively, Delete/move/protect [13:28:04] did anyone else esperience this issue ? [13:28:24] I'm experience much worse issues [13:28:29] my wiki fubared [13:28:35] znpy: what's your current language [13:29:22] RhinosF1: it should be english, and i'm pretty sure my browser is also sending english as an accepted language [13:30:14] RhinosF1: $wgLanguageCode = "en-gb"; [13:30:24] znpy: en-gb then [13:30:28] urgh [13:30:46] something's wrong ? [13:31:36] yes this was reported ages ago [13:31:51] ah, can you link me the issue ? [13:33:17] i'm gonna try and split that into $wgLanguageCode = "en"; / $wgDefaultLanguageVariant = "en-gb"; [13:33:26] the messages are in core wrong [13:33:30] sinceT303012 [13:33:32] T303012 [13:33:33] T303012: [subtask] Permissions based errors should not reuse messags intended for skin labels - https://phabricator.wikimedia.org/T303012 [13:33:40] Jdlrobson: ^ [13:34:00] it seems fixed [13:34:03] via the split [13:34:23] en will be right [13:34:31] en-gb very often ends p wrong [13:34:37] s/p/up [13:36:59] thank you RhinosF1 ! [17:14:12] hello [17:19:22] any suggestions for extensions to harden the mediawiki site? I don't for example want anonymous users to see the history or even see any of the special pages [17:53:50] Hey. On my fresh MediaWiki 1.38.1 installation, when I click on the "Read the user guide" link in the help menu of the visual editor, I get sent to https://my.wiki/index.php/Mw:Special:MyLanguage/ which shows a "Bad title" error page. I have checked the interwiki table in my DB and "mw" is in there. What might be the reason why this doesn't work? [17:57:12] anyone use the locdown extension? I'm trying to hide the special pages and history for all anonymous users [18:25:40] I can lockdown pages individually but why can't I do something like: $wgSpecialPageLockdown['*'] = [ 'user' ]; [18:26:10] avu: super wild guess since it's been a looooong time I've used VE or played around with it, but maybe the jQuery message parser (mediawiki.jqueryMsg RL module) doesn't support interwiki (and/or interlanguage, too) links? there certainly are (or at least were) some limitations to its capabilities when compared to wikitext parsing in normal contexts; {{SITENAME}} wasn't supported at least at some point [18:26:45] Peppi: because nobody's implemented such a feature? :) (but personally I'm just curious as to *why* you wish to hide special pages entirely from anons) [18:27:38] ashley, security reasons I guess, and I don't know what I don't know. Easier to just lock down all special pages from anonymous then individually lock them one at a time [18:29:58] that sounds more like security through obscurity rather than anything else [18:33:11] You cant lock all pages or you'd have no login Peppi [18:35:54] RhinosF1, I'm just trying to lock all special pages [18:36:03] Special:SpecialPages [18:36:41] Peppi: you can not lock all special pages. That would cause you to have no ability to log in [18:36:46] Which I'm guessing you don't want [18:37:04] If you want special:SpecialPages locked than that's not all of them [18:37:05] ashley, no that isn't security by obscurity. It's the opposite in fact. Currently having the special pages accessible to anonymous users is security through obscurity. [18:37:34] how is having special pages accessible security through obscurity [18:38:23] RhinosF1, well anonymous ussers could export the users and do a bunch of things "special" things hence the name [18:38:55] why would I or anyone for that matter want anonymous users to have access to Maintenance reports? [18:39:01] Peppi: that doesn't make it security through obscurity [18:39:15] Because they can fix some of them [18:39:28] fix some of them? [18:39:29] Because wikis are designed to be open [18:39:48] Yes, things like broken links or double redirects could be fixed by anyone on most wikis [18:40:35] RhinosF1, well I'm only interested in registered users doing that. Not anonymous bots. [18:40:41] also I'm not sure what you mean by "export the users" -- Special:Export and the API and such end points obviously do not provide access to other users' sensitive data like password hashes, user preferences, etc. [18:41:02] ashley, but their names [18:41:12] Which should be public anyway [18:41:24] Then restrict just them pages [18:41:31] yes? user names (and the specified "real names", if that feature is enabled) are considered public data [18:41:36] You restrict all pages and you break your wiki [18:42:00] RhinosF1, I'm not looking to restrict all pages just all special pages [18:42:17] Peppi: yeah I mean all special pages [18:42:23] You need some of them to function [18:42:26] MW was designed to be as open as possible, not the other way around; so as per [[mw:Security issues with authorization extensions]], you may run into unexpected complications while trying to lock down access in ways that were never meant to be done [18:42:56] kk [18:44:22] so basically I have to go to: https://foo.wiki.com/Special:SpecialPages and manually restrict the 40 links that are there then [18:45:55] yes [18:46:36] You could probably make a hook do it tbh but I guarantee that would break things in weird and wonderful ways [18:47:54] I'm not sure why anyone would want anonymous users to have access to Data and Tools, or Media reports and uploads, recent changes and logs and so on and so forth... but it is what it is. [18:48:08] because it's a wiki open to everyone [18:49:22] Being able to read a wiki and being able to access it's API anonymously are two different things. [18:51:03] You can use the SpecialPageFactory's getNames method to get the list of names [18:51:30] But like Rhinos said, restricting access to all Specials would definitely break things [18:52:03] Importantly, users would not be able to log in anymore [18:52:56] well I could whitelist pages like login [18:55:36] Lockdown doesn't have a native whitelist function [18:56:07] RhinosF1, no it only can take away rights it does not give [18:56:11] An alternative may be to make your wiki private and whitelist the pages everyone is allowed to read through wgWhitelistRead [18:56:39] Marijn[m], perhaps. I'll have to look into that I guess [18:57:32] That is well supported and considered safe [18:59:38] Marijn[m], ya the only issue is then every page we need to explicitly allowed in that case. [19:00:45] would have thought this would be an easy use case to handle. There are people asking about it for over 10 years... [19:06:04] MediaWiki was made to be open, and Wikimedia have stuck to that philosophy. But I agree, not having proper access control features makes MediaWiki much less usable for enterprise applications (even though it is a really powerful tool and well suited as CMS if it had these ACLs)... [19:07:55] I'm ok with open for people to read. I'm not ok with open for bad agents to DOS or take user data. [19:08:45] I assumed special pages would be pages that do "special" things and therefore would be easy to lock down. [19:09:11] Special pages are locked down, but they are accessible [19:09:23] But they never allow an actor to do something malicious [19:09:35] Wikipedia is open, and it is fine with having no restrictions on special pages [19:09:37] how are they locked down yet accessible? [19:10:16] They are accessible, but not everyone can do everything with all special pages [19:10:39] I mena if I was a bad actor I could just have a bot crawl the internet and DOS every wiki system via the API sandbox [19:11:14] but ok it is what it is. It can't so that [19:11:17] There are reasonable and configurable limits in place to prevent that [19:11:17] that's that [21:40:36] hi, we have a template that adds links to a particular website, it looks like this: [21:40:42] [https://slovnikcestiny.cz/heslo/{{#if: {{{1}}}|{{PAGENAME}}/{{{1}}}|{{PAGENAME}}}} {{{2|{{PAGENAME}}}}}] [21:40:46] but for some reason the template adds "%7B%7B%7B1%7D%7D" on the end of the link [21:40:53] why is that so? [21:40:57] how to prevent it? [22:10:12] because when decoded that resolves to a literal {{{1}}} [22:10:37] aka the thing using your template isn't passing the first unnamed parameter, and your #if is broken because you didn't make the parameter optional [22:10:49] you'll want {{#if:{{{1|}}} there [22:10:52] note the extra |