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).

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.

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.)

See T331214: “MWContentSerializationException: The provided entity serialization is neither legacy nor current” on Beta Commons for context.

See T331214: “MWContentSerializationException: The provided entity serialization is neither legacy nor current” on Beta Commons for context.

File:ACDC test file 2.pdf is also affected. Both files can still be downloaded via Special:FilePath:

Uh, yeah, this sure doesn’t look like MediaInfo content to me.

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.

One strange thing I noticed today (Mastodon post) is that this HTML is only returned for a subset of items.

\o/ thanks for merging!

It turns out Special:OAuthManageConsumers already shows this information, but that’s not accessible to everyone.

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):

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.

In T323956#8437053, @MarkAHershberger wrote:

Next, I saw that @LucasWerkmeister said that wikimannia was "judged to be harmful to young people by the German government in 2020" and read the linked article (via Google Translate) but I don't see any mention of the German government. (I saw information about cases against them for copyright violations but that is not at all the same thing.)

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.)

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.

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.

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.

So if you have shell access, you can work around this / T291679 using:

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.

(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.