[07:31:17] https://t.me/+H_pU7iax8cViM2Vk [11:57:12] Does anyone know what does the error "Unable to continue login. Your session most likely timed out" in API actually mean? (I am using a fork of an extremely old version of Wiki.java and trying to figure out how to fix stuff with the smallest effort [11:57:21] It broke around half a year ago or so [12:09:41] it could be the removal of ancient methods to retrieve CSRF tokens, though that was more like one year ago https://www.mediawiki.org/wiki/MediaWiki_1.37/Deprecation_of_legacy_API_token_parameters [12:15:06] I think that thing broke something too but then I fixed it, let me see how I retrieve those atm [12:16:30] String response = post(apiUrl + "action=login", buffer.toString(), "login"); [12:16:30] hm, it looks that by running a post request to a login EP [12:16:40] but it does return a token [12:17:57] That was deprecated five years ago. [12:18:51] Just send an action=query&meta=tokens request, it shouldn't be much effort. [12:20:20] :( (re @gtisza: That was deprecated five years ago.) [12:22:49] Voting via wikicode is simple and avoids change aversion. If you don't care about those two things, I don't think there is much point in implementing the voting system within MediaWiki - writing or using a standalone tool is much quicker, and it allows dumping a bunch of conventions which were forced by the use of wikitext, such as making the votes public, or using simple yes/no [12:22:50] voting systems. (re @waldyrious: I don't have any plans, really, just curious since community votes have been central to the Wikimedia movement since very early,...) [12:26:18] done, but the original problem remains (re @gtisza: Just send an action=query&meta=tokens request, it shouldn't be much effort.) [12:29:21] https://phabricator.wikimedia.org/P35382 [12:29:32] meh it does not get previewed [12:29:42] makes pastes useless [12:30:13] this is how I log in. it works via ApiSandbox thought there is a warning suggesting to use the annoying bot passwords [12:35:51] what else is involved in the login besides the token? shall I look if some session cookie is there? [12:36:10] was something changed in how it is returned recently? [12:36:24] (though I cannot really think how that can be myself) [12:39:59] I was going to ask if it’s a bot password or not, I wasn’t sure if that API even still supports non-bot passwords at all (re @Thecladis: this is how I log in. it works via ApiSandbox thought there is a warning suggesting to use the annoying bot passwords) [12:40:29] is there anything else in the API response? [12:40:48] well if it works via ApiSandbox I would assume it shall work via an external client too [12:41:58] not really (re @lucaswerkmeister: is there anything else in the API response?) [12:42:11] added the api sandbox and the java client responses to https://phabricator.wikimedia.org/P35382 [12:44:13] (changing api sandbox output format to xml as long as I use a new token does not break it either [12:44:35] though I initially got the same expired session output when reused the same token [12:45:18] I can’t remember any relevant change from ca half a year ago at the moment [12:45:33] (if it was a few weeks ago, I’d suspect that maybe PHP 7.4 introduced some very subtle change to session handling) [12:46:05] to me it sounds like wiki.java somehow isn’t persisting the session properly, doing something wrong with the cookies or something [12:46:16] maybe you changed the Java runtime version in the meantime and that introduced a change? [12:46:48] (wild guess: you’re connecting to the API via HTTPS, not HTTP, right? maybe the cookie store is treating http(s)://en.wikipedia.org as separate sites?) [12:47:38] hmm, well there might have been a java runtime upgrade but I am not sure it would be a factor, I am using some old version of java, not sure which one 7 probably [12:47:44] searching finds someone with the same issue in march, where the sandbox works but their bot doesn't, and they get the same error whether the login is correct or not [12:48:36] but vb not java, it seems [12:49:04] yeah saw that one (re @Nikki: searching finds someone with the same issue in march, where the sandbox works but their bot doesn't, and they get the same error...) [12:50:37] yeah, I'm mostly just mentioning it for people like lucas who might have some idea of what could've changed around that time or earlier, since they didn't seem to find a solution [12:52:00] someone else seem to be saying they haven't been able to connect since february [12:52:42] (it's in french so maybe I misunderstood it https://fr.wikibooks.org/wiki/Utilisateur:OxBot) [12:52:45] You should use the annoying bot passwords. [12:52:55] Or preferably OAuth 2. [12:53:30] But there aren't any plans right now to drop the old login API, it's just deprecated (and fails in situations where a second login step would be needed). [12:53:38] Well OAuth 2 is a pain. I tried using it in a newer code and I barely managed to get hold of it after days of trying :) [12:54:09] Definitely not something I am ready to do in this old code form 2013 in a language that I last dealt with in 2017 or so [12:54:50] though 2 is simpler than 1.1 or whatever was the previously supported version (re @Thecladis: Well OAuth 2 is a pain. I tried using it in a newer code and I barely managed to get hold of it after days of trying :)) [12:55:32] I'd just add some sort of config flag for OAuth mode, and when present send the password via the Authorization header instead of the login API. [12:56:00] When starting from scratch, it's way simpler than login state management. [12:56:39] Anyway, session errors mean either cookie handling problems or an invalid/missing CSRF token. [12:57:41] I wonder if it could possibly be some sort of encryption problem? I've noticed various old non-mediawiki things breaking over the past few years as things switch to different encryption methods [12:57:43] If the code didn't change, then I'd guess a cookie jar handling change in Java. [12:58:45] The only client-side encryption involved is HTTPS, and if that wouldn't work, you wouldn't see the API response at all. [12:58:55] hmm, lemmi see if I can put cookie management into a more explicit realm… [13:08:02] hmm [13:08:46] the code checks for a "Set-Cookie" header. But the one received seems to be "set-cookie". Were headers lowercased? [13:09:03] I guess they might have been at some point [13:09:13] cookie headers should always be treated case-insensitively, though [13:11:23] lol changing `equals` to `equalsIgnoreCase` solved the problem :P [13:11:48] thank you everyone :) [13:21:56] \o/ [18:27:35] how can I access a class from an extension in LocalSettings.php? [18:28:21] (or alternatively how can an extension make a class accessible to LocalSettings.php?) [18:28:53] what are you trying to do? [18:29:22] why isn't a config variable enough? [18:29:34] You can probably do it in a callback... But what are you trying to do? [18:30:31] I want my extension to define an interface with various functions and then have users implement those functions ... and I don't want to use hooks since the functions HAVE to be implemented (whereas hooks usually are optional) [18:31:06] so I think I'd still have a config variable $wgMyExtension_controller = new MyController(); ... dunno if it works that way [18:31:23] where class MyController extends ControllerFromExtension { ... } [18:32:41] but ControllerFromExtension in this case would be defined by the extension [18:33:58] I’d probably use a config setting that contains an ObjectFactory specification https://packagist.org/packages/wikimedia/object-factory [18:34:22] and then extensions could specify a callback, and by the time the callback is called, the class is ready for autoloading [18:35:19] (similar to e.g. $wgSessionProviders and $wgMWLoggerDefaultSpi) [18:36:47] what's the point of the object factory? [18:37:31] standard way of creating objects with dependency injection in mediawiki 🤷 [18:44:38] huh ... I guess I specifically want my extension to define an abstract class with abstract functions and have LocalSettings define a class extending that abstract class [18:44:56] so that not defining the required functions leads to a fatal error [18:46:02] and ideally I'd like to achieve that without introducing any new dependencies [18:47:17] surely it must be possible to make a class accessible to LocalSettings? [18:49:01] You could in a callback [18:50:28] how? [18:50:46] I guess you don't mean https://www.mediawiki.org/wiki/Manual:Extension.json/Schema#callback ... because that apparently happens after LocalSettings [18:51:41] https://www.mediawiki.org/wiki/Manual:$wgExtensionFunctions [18:51:44] You can use/abuse that [18:54:14] You could also use a config variable with the class name.. And have it instantiated later whn the class will be available [18:54:26] (but then you're getting towards reinventing objectfactory) [18:55:11] What are you actually trying to do? [18:58:36] I need extension users to define several functions and I think the best way to enforce that is by having them extend an abstract class with abstract functions [18:59:30] why do they need to define functions? [19:01:32] so that the extension can integrate with an arbitrary external system/API [19:02:28] You could make them make an extension that depends on your extension too.. [19:02:44] The amount of extra work vs just stuffing it all in LocalSettings should be minimal [19:03:57] Reedy beat me to it. I think there are already examples of this. [19:04:25] There's a few of the auth plugins that do that [19:04:29] yes I know that I could make them make an extension ... but it's definitely easier to say "paste this into your LocalSettings.php and fill in the blanks" than it is to say create a new extension [19:04:48] You can do it with config variables... and throw runtime exceptions if they're not defined correctly [19:05:32] PHP is pretty loosely typed [19:05:45] So if you're gonna do the copy paste.. you don't even need the abstract/base class/interface [19:06:54] when you extend an abstract class PHP at least checks that the functions have the right amount of parameters [19:07:55] If you can't trust people to copy paste a template correctly... [19:08:09] and actually even a wrong type declaration leads to a fatal error [19:08:11] ... I just checked [19:08:24] (I meant parameter type) [19:09:07] $wgExtensionFunctions[] = function() { class Foo extends Extension\Foo { public function bar() { } } } [19:11:00] thanks, I'll try that [19:11:33] When the callback runs, everything should be available (extension classes and such) [19:12:06] it's not really about copy'n'paste errors ... I want to be able to make breaking changes to the API in the interface in the future and have that result into an instant fatal error instead of an error that only happens sometimes [19:15:03] huh it says class not found [19:15:51] re “without introducing any new dependencies”, MediaWiki already depends on objectfactory [19:16:11] (and that also lets you assert that it’s an instance of a certain class, https://github.com/wikimedia/object-factory/blob/5fb1013d2440abc6f6c46675fe1bcfd5f43b262e/src/ObjectFactory.php#L141-L142) [19:16:45] right but I'd still need to set up composer I guess? [19:17:04] and require users to do a composer install? [19:17:33] no? if your users have a working mediawiki, then it includes the objectfactory somewhere [19:17:40] (either via composer or by cloning vendor.git, I guess?) [19:17:47] or included in the tarball [19:17:53] but either way, you can get an object factory form the MediaWiki service container [19:18:06] and that’ll be wired up for dependency injection already [19:27:21] I don't see how using an object factory makes sense here ... that would make sense if the extension users didn't know the concrete class ... but the concrete class is known [19:27:52] and Reedy ... your $wgExtensionFunctions[] trick for some reason doesn't appear to be working [19:29:19] Is it syntactically correct? [19:30:05] yes [19:31:16] but new Extension\MyExtension\MyClass(); doesn't work ... it says that the class isn't found ... I also tried MediaWiki\Extension\MyExtension\MyClass to no avail. [19:31:34] and MyClass is added to AutoloadClasses in extension.json [19:36:49] okay interesting I just var_dumped get_declared_classes() in a $wgExtensionFunctions[] function and there are no Mediawiki\Extension classes defined ... at all [19:36:55] $wgExtensionFunctions[] = function() { [19:36:55] var_dump( \MediaWiki\Extension\AbuseFilter\AbuseFilter::HISTORY_MAPPINGS ); [19:36:55] }; [19:37:05] that work sfine [19:38:44] interesting it doesn't work for me [19:39:12] I am testing this with MediaWiki 1.38.1 ... how about you? [19:39:15] master [19:39:31] this should work back to much much older MW just fine [19:39:53] so just adding this to LocalSettings.php works for you? [19:40:02] Yes, after the wfLoadExtension( 'AbuseFilter' ); [19:40:36] I wouldn't worry about get_declared_classes() not having your class in it [19:40:38] ah ... yeah of course I forgot that [19:40:41] ok now it also works [19:41:41] for some reason it doesn't work for my extension :/ [19:41:45] I'll try to make a minimal example [19:47:48] extension.json: {"name": "Foo", "manifest_version": 1, "AutoloadClasses": { "Foo": "Foo.php"}} [19:48:17] Foo.php: and in LocalSettings.php: wfLoadExtension( 'Foo' ); $wgExtensionFunctions[] = function() { var_dump( \MediaWiki\Extension\Foo\Foo::FOO ); }; [19:49:12] doesn't work for me [19:49:15] It's because you're doing it wrong [19:49:22] You've not declared the class as being namespaced [19:49:31] You've not declared it in the autoloader definition as being namespaced [19:49:34] that should just be \Foo::FOO in the extension function, I believe [19:49:39] Therefore when you use it, it's not going to be namespaced either [19:49:43] classes don’t end up in a namespace automatically [19:50:11] (and plenty of extensions still aren’t namespaced, though e.g. Scribunto has recently been converted I believe) [19:50:39] ooooh [19:51:49] so do I just add namespace Foo; to the .php file? [19:52:23] You need to fix your AutoloadClasses entry too [19:52:40] ah ok [19:52:57] Though, generally, you should use AutoloadNamespaces these days [19:53:00] Makes life easier [19:53:07] namespace MediaWiki\Extension\Foo; probably [19:53:09] also +1 AutoloadNamespaces [19:55:40] (and also, use manifest_version: 2 too) [19:59:58] wohoooo I managed to get it working :) [20:00:16] what a struggle ... I wasn't sure when to use the leading backslashes [20:01:24] apparently in LocalSettings.php they are optional but in extension.json and in the namespace declaration you don't want them [20:02:33] extension.json shouldn't care [20:02:54] IIRC we have extensions that do use : "\\MediaWiki.... [20:03:34] for me it doesn't work when I do : "\\MediaWiki... in extension.json [20:03:40] *\ [20:04:02] ok ... I cannot send two backslashes I think [20:04:52] hmm, curious [20:05:03] looking at the extension repo... You might be right [20:05:11] or we've replaced them [20:05:18] It's used in other fields where a class name is used though [20:05:23] "callback": "\\Flow\\Hooks::getTermsOfUseMessagesParsed", [20:05:24] etc [20:05:48] well thank you both very much :) [21:55:46] In PHP, how can I get a list of all possible namespace names? I'm using $wgCanonicalNamespaceNames at the moment, but i need uncanonical ones as well (`Image:` especially, but also any other extra ones). I'm fine with combining several arrays to get this, as long as i capture every possible namespace [21:59:31] `MediaWikiServices::getInstance()->getNamespaceInfo()->getValidNamespaces()`, I think [21:59:41] (or get a `NamespaceInfo` instance via dependency injection) [22:00:02] .* [22:00:24] that's too broad (re @wmtelegram_bot: .*) [22:00:29] thanks, will try! (re @lucaswerkmeister: MediaWikiServices::getInstance()->getNamespaceInfo()->getValidNamespaces(), I think) [22:00:31] you win some, you lose some [22:00:33] oh, namespace *names*, sorry [22:00:35] I missed that [22:00:36] is this a regex? (re @wmtelegram_bot: .*) [22:00:51] yup [22:01:32] namespaces can't have colon or anything that's not valid in a page title right? [22:01:58] yeah, i may have worded it poorly: i need all names for the valid namespaces in the wiki. not theoretically valid names, but actually valid names [22:02:33] right I got that :) (re @jhsoby: yeah, i may have worded it poorly: i need all names for the valid namespaces in the wiki. not theoretically valid names, but act...) [22:02:35] you can get them via the API here https://incubator.wikimedia.org/w/api.php?action=query&meta=siteinfo&siprop=namespaces|namespacealiases&formatversion=2 [22:03:04] and maybe figure out where `ApiQuerySiteinfo.php` gets them from