[00:05:51] ... because my gut feeling would be: it makes sense, that the something needs to be checked after a hour, but that should be something in the background, not disturbing or encumbering the user - or worse [00:08:38] That setting is the time-to-live for an idle session in cache. I don't think that WSOAuth has the $wgExtendedLoginCookieExpiration to fall back on to create a new session once an idle session has been reaped. [00:10:20] I use `$wgObjectCacheSessionExpiry = 86400;` in my test wiki. In a more widely used wiki I would probably set it to 604800 or so (assuming that the user pool was reasonably sized) [00:10:49] 86400 === 24 hours; 604800 === 7 days [00:13:31] OTOH logging in is pretty effortless with WSOAuth, you just click the login link and you are done. So there is little harm in the inactivity threshold being low. [00:14:11] unfortunately i lack the necessary knowledge of all the parts, i just know that when logging in via oauth2 on my setup (with nextcloud), i get a redirect to a "Connect to your account" page, then a "Grant access" page, and then i'm back at the wiki (loosing the information from where i started off along the way). I have not yet figured out, why this is so. [00:14:56] so i'd be very happy for any pointers how to fix my setup to have a effortless login via nextcloud ... [00:26:59] tgr_: hmm ... i just realize, you mention "WSOAuth" ... i had used "OAuth2_Client" ... do you happen to know ... if that would make a significant difference? Or by reading the docu of WSOAuth now: how to use that for connecting to Nextcloud? (It currently only seems to support MediaWiki itself and Facebook) [00:28:55] Yeah, WSOAuth does not support Nextcloud (although probably easy to add). I'm not familiar with the OAuth2 extension at all, not sure if it does something in a suboptimal way, or the limitation is on the Nextcloud side. [00:29:28] There isn't any disadvantage to increasing $wgObjectCacheSessionExpiry, in any case. [01:02:41] @Yaron: External Data composer.json on REL1_39 has a requirement of composer/installers of ~2.1. [01:02:41] Current latest version is 2.5.4, which doesn't match. [01:02:42] Could this be expanded please? [01:03:41] most of the other extensions I have with a requirement use ">=1.0.1". [01:03:41] SimpleBatchUpload uses "^2|^1.0.1" [01:05:58] actually, I'm not sure if even that works. [01:05:58] - Root composer.json requires composer/installers ~2.1, 1.*,>=1.0.1, found composer/installers[dev-main, v1.0.0, ..., 1.x-dev, v2.0.0-alpha1, ..., 2.x-dev (alias of dev-main)] but it does not match the constraint. [06:06:10] The images here are not playing well with the responsive img rule 'max-width: 100%;' https://wiki.documentfoundation.org/Design/Branding#Logos_2 [06:06:48] They get a width set with 300px, but that apparently also gets them a hard-coded height property... [06:07:52] somehow it's unexpected per https://www.mediawiki.org/wiki/Help:Images#Syntax "maximum width in pixels, without restricting its height" [06:09:46] ooh I have a typo in CSS... [06:10:40] thank you for attending my rubberduck debugging session [06:17:21] buovjaga, in case you need slightly less rubber duck, there's some discussion about the inline style in T282588 [06:17:22] T282588: images wrapped in flex item styling get really small in Timeless/Minerva - https://phabricator.wikimedia.org/T282588 [06:17:44] that task also applies to tables without widths set, apparently [06:21:14] thanks [07:59:19] can anyone help with autowiki browser? [08:03:27] on autowiki browser how do you exactly put a miraheze domain so it recognizes it [09:23:56] hi, is there any support for downgrading MediaWiki? I just realized LDAP authentication is broken on 1.39 [09:34:39] taylan: no, downgrades are not supported [09:39:24] which LDAP extension are you running? [09:39:36] and what error messages are you getting? [09:47:59] p858snake: is there anything other than PluggableAuth + LDAPAuthentication2 ? I'm facing the same issue as described here: https://www.mediawiki.org/wiki/Extension_talk:LDAPAuthentication2 some talk about it also here: https://www.mediawiki.org/wiki/Extension_talk:PluggableAuth [10:30:16] aha, checking out REL1_35 for both PluggableAuth and LDAPAuthentication2 (but *not* for LDAPProvider and LDAPUserInfo) worked :D [10:31:02] if those versions work fine with 1.39, I wonder why there even is a REL1_39 branch that's just broken [11:01:21] seems that LDAPAuthentication2 can also be at REL1_39, it's just PluggableAuth that needs to be rolled back. what's weird is, I had checked out the tag 5.7 on PA and it had not worked, which is why I thought further steps are necessary, but I guess REL1_35 is not exactly the same as 5.7. I don't understand what the REL branches are for tbh. [11:03:30] @taylan, there might be something useful in https://phabricator.wikimedia.org/project/board/861/query/all/ [11:04:26] REL is just forks that are made when core gets released. they are automatic, so if an extension maintainer didn't update the code to be compatible, it can still be broken. [11:04:41] * is just extension forks that [12:55:39] yup, the REL_* branches are an unfortunate accident that simply happens, no matter what [13:47:27] I'm trying to call a translatable template within a translatable template. Earlier I had copied the Template translation module and the associated templates and now I tried with {{TNT|.. and {{ {{TNTN| .. but it's not working [13:47:29] https://wiki.documentfoundation.org/Template:Documentation/Calc_Functions/COUP_Functions_Arguments [13:47:38] trying to include https://wiki.documentfoundation.org/Template:Documentation/Calc_Functions/FinancialFunction_Basis [13:48:18] translation aware transclusion is enabled for both [13:52:13] https://wiki.documentfoundation.org/Template:TNTN [13:55:13] normal use of TNT works at least [21:08:11] Hello everyone, I am still struggling to get oauth 2.0 work with postman, since from 2 months ago, lol... today I decided to start everything from fresh, new server, new installation 1.39.2, but still getting same error in postman: "readapidenied", can anyone help me to do some troubleshooting? I have the test instance set up and u can do anything [21:08:11] u need to: http://test.papals.org/ [21:08:49] BTW, it is a private wiki, no external users can view anything, but I can create a user if needed. [21:11:40] I think i said this last time, but my go to guess would be missing Authorization header, or something wrong with how it is encoded [21:11:52] depending on which stage of the process you get the readapidenied error [21:13:45] Thanks bawolff, can you do me a favor if you can try it from your end? I can give you the Access token. it is brand new install there is no sensitive data or whatsoever on the wiki [21:14:13] I really dont know what my next step is at this time.. lol, I have tried all I can within my knowledge... [21:15:42] after i created the oauth 2 consumer record, all I did was to open postman and trying to query a page "TestPage" using this endpoint: http://test.papals.org/api.php?action=query&format=json&titles=TestPage [21:16:06] and passing the access token in the header, in postman [21:16:39] which was suggested to do in this page: "Using an owner-only app in OAuth 2 is very simple. Just register the app via Special:OAuthConsumerRegistration/propose (make sure to set the protocol version to 2.0) with the option "owner-only" checked. (In case of a wikifarm, the special page is only available on the central wiki of the farm. In case of [21:16:39] Wikimedia, it's at meta:Special:OAuthConsumerRegistration/propose.) Then, record the access token that's shown when submitting the form, and sign your API requests by adding the HTTP header Authorization: Bearer . " https://www.mediawiki.org/wiki/OAuth/Owner-only_consumers [21:20:35] I have also made sure cache is enabled, and "Special:OAuth" is added to whitelist per https://www.mediawiki.org/wiki/Extension:OAuth [21:21:55] paulx: sure, i can try [21:22:26] Hi, I have an issue loading thumbs into MediaViewer. [21:22:51] Access to image at 'https://pool.dbg-web.de/w/images/0/0e/Andre_-_Bromeliaceae_Andreanae.jpg' from origin 'https://de.dbg-web.de' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. [21:22:52] This is basically the error. [21:23:15] paulx: Also, its been a while, but i vaugely remember OAuth2 might have required rest.php instead of api.php for some parts [21:23:28] bawolff Greatly appreciate it! how do you want me to send the access token? [21:23:29] I didn't really follow the version 2 upgrade (And am not a fan of rest.php in general) [21:23:38] bawolff: it does [21:23:39] you can private message me if you want [21:23:43] I added [21:23:43] $wgCrossSiteAJAXdomains = [ [21:23:44]     '*.dbg-web.de' [21:23:44] ]; [21:23:52] This did not help either. [21:23:53] but don't ask me too much either [21:24:19] Guest95: $wgCrossSiteAJAXdomains is for something else, so it won't affect that [21:24:33] just for the fun of it I also added         Header set Access-Control-Allow-Origin "*" to htaccess [21:24:38] Still no luck. [21:24:55] Ok, this explains why it does not work. [21:25:13] Guest95: the .htaccess one is probably more the right thing to do, but be sure you set it in the correct .htaccess (has to be in images) [21:25:44] Another complication is that the foreign file repo is only readable for logged in users though it does not use image auth. [21:26:38] This is probably not the issue since I can very briefly see the thumb in MultimediaViewer befor it errors out. [21:26:40] Oh, if you are using img_auth.php, then things get more complex. At the very least, you can't use "*" as your access-control-allow-origin, you have to use the actual domain [21:26:52] No, not using image auth. [21:27:17] oh, i misread that [21:27:34] if you're using some other method that relies on cookies, it'd be the same thing [21:27:58] The brief flash, probably means it can load the initial image, but not the high resolution version [21:28:08] which would be consistent with a CORS error i think [21:28:19] maybe, i don't know enough about how multimedia viewer works [21:30:59] not sure what to do either? [21:31:32] somehow i need to get the thumbs from the foreign file repo to the consumer. I guess this should work. [21:36:03] Guest95: I'm a bit confused about the access control part. Do you have something preventing logged out users from viewing images? What is it? [21:37:46] $wgGroupPermissions['*']['read'] = false; [21:38:09] this is on the repo [21:38:20] on the consuming wiki there is no restriction [21:38:43] also tried with and withoug thumb handler. does not make a difference. [21:48:09] I will disable MultiMediaViewer. [21:48:37] Does not matter in the end though it would have been nice to have it. [21:48:51] Thanks for trying to help. [21:48:52] Guest95: in that case, that doesn't add any restrictions to images, so probably shouldn't matter [21:49:16] So really, your .htaccess you mentioned earlier should have done the trick, as long as you put it in the .htaccess in the repo [21:51:53] No it did not. I am out of luck. [21:53:33] Bye!