Private account of @Lucas_Werkmeister_WMDE (he/him, Berlin timezone). Anything I do here is on volunteer time, even if it looks work-related :)
User Details
- User Since
- Jun 5 2016, 4:36 PM (354 w, 5 d)
- Availability
- Available
- IRC Nick
- lucaswerkmeister
- LDAP User
- Lucas Werkmeister
- MediaWiki User
- Lucas Werkmeister [ Global Accounts ]
Wed, Mar 22
Thu, Mar 16
The API sandbox output formats are customizable via the apisandbox.formatRequest JS hook (see the m3api ApiSandbox helper, source code, for an example), so you could prototype this as a user script if you want, before adding it to MediaWiki core (if that’s the intention here).
Wed, Mar 15
Mon, Mar 13
So I think a relatively simple fix would be:
- merge those two style attributes into one
- to be nice, also add something like <noscript>JavaScript needs to be enabled to use this form</noscript>
Thanks. With no JS (F36910309), here’s what I see:
I can’t easily test this again, since the bot now tells me “You have already requested a cloak, please wait for the request be processed”. As far as I can see in cloak.html on GitLab, the submit button should have been wrapped in a style="display:none" element, so I’m not sure why it still worked for me.
Wed, Mar 8
Mon, Mar 6
Sun, Mar 5
And now the AC/DC browser tests work again \o/
Okay, this worked:
(Correction: I could delete the 2.pdf file, but I don’t want to do that while 1.pdf is left behind.)
File:ACDC test file 2.pdf is also affected. Both files can still be downloaded via Special:FilePath:
Also, the wikitext content (main slot) can be retrieved with a command similar to the above (change the slot, then call getText() on the content; sudo no longer required): P44931 and P44932.
Uh, yeah, this sure doesn’t look like MediaInfo content to me.
Sat, Mar 4
Fri, Mar 3
Thu, Mar 2
FWIW, my QuickCategories tool, which as far as I’m aware works in a broadly similar way (store what requests-oauthlib calls the resource_owner_key and resource_owner_secret in the database, later read them to recreate an authenticated session), still seems to be working fine: batch #5962 ran in the background yesterday, 14:30 PM.
Sun, Feb 26
Sat, Feb 25
One strange thing I noticed today (Mastodon post) is that this HTML is only returned for a subset of items.
Feb 20 2023
Feb 15 2023
Feb 14 2023
Feb 9 2023
Jan 31 2023
Jan 29 2023
Jan 15 2023
Dec 28 2022
Dec 26 2022
Dec 21 2022
\o/ thanks for merging!
Dec 11 2022
It turns out Special:OAuthManageConsumers already shows this information, but that’s not accessible to everyone.
Dec 9 2022
Just adding some more relevant terms to this task so it can be found more easily via search – this limitation of two-factor authentication is mentioned in the current WikimediaMessages version of the wikimedia-webauthn-ui-login-prompt message on the login page, which states (since T248367):
Dec 7 2022
I offer an initial implementation: https://github.com/bd808/SAL/pull/22
👍 thanks!
I’m only filing this task, and not chmod’ing the file myself, because I don’t know if anything else relies on the file being readable, and because the risk of leaving it open a bit longer seems comparatively low to me.
Dec 6 2022
Dec 5 2022
Dec 4 2022
Dec 1 2022
Nov 29 2022
Nov 28 2022
Filed a PR proposing to remove this and another similar-looking repo at WMStake/nonwmf-extensions#40. (Note to self: if it’s accepted, also make another pull request for nonwmf-skins.)
(And the seventh one is in MWStake’s nonwmf-skins, this commit.)
Probably via MWStake? Bunch of freshly found extensions added six of them.
(Related task: T317989: Remove archived GitHub repos from codesearch proposes the removal of one of the seven repositories on grounds of it being archived.)
Nov 27 2022
I suppose there is one way to tell whether a client is confidential or not: try to go through the authorization code flow using only its client ID. If it worked, then the client must be non-confidential ^^
Also relevant to T234677: Support Free and Open Source software API clients with OAuth 2.0, I think (a FLOSS browser-based application using a non-confidential OAuth client should be able to make authenticated cross-origin requests, similar to an owner-only client).
My understanding is that this task is mostly done, because MediaWiki nominally supports non-confidential clients now: you can indicate at consumer registration time whether a client should be confidential or not, and non-confidential clients can get an access token and make authenticated requests based on only their client ID, without using the client secret.
Nov 26 2022
Although MediaWiki still generates a secret key for non-confidential OAuth 2.0 consumers (idk why), and if you use that secret key, you can still successfully use the refresh token.
Nov 21 2022
Ah, sorry for the confusion – indeed I accepted the users, and then saw (looking through some other requests) that @rook usually asks people to attach their Phabricator accounts, and so I sent additional comments to the users who didn’t have a Phabricator account attached yet.
Nov 19 2022
Nov 15 2022
Nov 14 2022
So if you have shell access, you can work around this / T291679 using:
Nov 13 2022
I can see the existing record sets in the beta.wmflabs.org zone in deployment-prep horizon, but I can’t create a new record set myself, probably because I’m only a user but not an admin of the project. (In the tools project, on the other hand, I have a “create record set” button available.) But I agree that adding that DNS record would probably help with this issue – my mail server logs look pretty similar, and mx-out03.wmcloud.org still seems to be the right domain (or instance-mx-out03.cloudinfra.wmflabs.org – both have the same IP address).
Ask the user to authorize the application by sending them to oauth2/authorize under the wiki's REST endpoint (usually rest.php), with response_type=code and the client token (as client_id), and ideally also a request_url and state.
Nov 10 2022
Nov 7 2022
Nov 5 2022
Oct 30 2022
(Done with the help of these docs linked by @taavi, btw.)
Should be done, I think. The pods quota had been increased in T283970 (from 4 to 7, I think), but it seems that since then it was increased even further for all tools (to 10), so I didn’t decrease that one.
(There are no rows with rev_deleted != 0 or log_deleted != 0 in either table, by the way, so I think they should be okay to publish in full.)
The partial SQL dump includes the following tables:
Clearly I couldn’t be bothered to do any fancy HTML-level snapshotting so far, so let’s just do a partial database dump. Using an allowlist of tables as suggested by @Jdforrester-WMF seems simpler.