@Niharika We've run into several edge cases regarding localization of foreign namespaces. Even "common" namespaces can have issues (for instance, Project namespace may be overridden on different languages). @Tchanders and I would like to propose a new solution: Instead of listing the pages and namespaces, we'll instead say "3 pages" or "2 namespaces" and that text will link to the Special:BlockList on the local wiki. Then, if we'd like to expand that list later, we can do so with T226651 which will make client-side API requests to get the localized pages and namespaces. How does that sound?

In T235389#5572340, @Lucas_Werkmeister_WMDE wrote:

I don’t understand what this means. What kind of access are you talking about? Because the Query Service can’t be accessed from wikitext (parser functions or lua) either.

I feel like it would be somewhat difficult to correlate Wikidata-Query-Service usage with CheckUser usage, how would you go about doing that (especially if a tool existed for anyone to do a reverse-lookup of any IP address with the same type of query)?

In T235389#5571261, @Reedy wrote:

Again, MW has functionality for doing this conversion, splitting, reformatting etc. You could store a start, store an end of the range like we do elsewhere for ranges. Wikibase stores most things in json blobs, so not like we're going to need schema changes, and storing a couple of extra fields for a property that aren't that widely used... Doesn't seem like a storage consideration we really need to care about

In T235389#5571220, @Reedy wrote:

Not really, and MW has functionality for telling you that. Wikibase could expose/use that

@Tchanders & @Niharika when the UI says: "global users list" is that just Special:GlobalUsers ? If so, it looks like GlobalUsersPager::getQueryInfo to ensure that only users who are not hidden in any way are shown:

$conds = [ 'gu_hidden' => CentralAuthUser::HIDDEN_NONE ];

or are we talking about some other page?

In T226995#5568090, @Niharika wrote:

@dbarratt Are you still working on this task? We could drop it from the board, otherwise. I'd rather wrap up blocks and get started with CU now.

@Niharika there is an open question from @Tchanders, I think we talked about it but didn't come to a resolution:

With this change, the account is no longer hidden when an admin chooses "Account is hidden from the global users list" in Special:CentralAuth.
If we wanted to allow a user to be hidden but not blocked, we'd need to reintroduce something like the UserIsHidden hook, and set the mHideName flag directly on the User, without setting a block.
I don't think we should do that - the fact that a user cannot now be hidden without a block is not a regression, but an intended consequence of deprecating the UserIsHidden hook (explained in T228948).

https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CentralAuth/+/534849#message-4ea3c3988f99592353e78565ede94973db385139

I went ahead and merged this, giving @dom_walden an opportunity to QA (if you want it). :)

This looks good to me so I've merged it, I can deploy it whenever, but wanted to give @dom_walden an opportunity to QA (if you want) before deployment. :)

https://github.com/wikimedia/InteractionTimeline/pull/115

In T6845#5333593, @EvanProdromou wrote:

I'm diving on this grenade until or unless someone else takes it over. I'm very interested in using our Captcha system for doing micro-curation tasks (both for visual and non-visual contributions), either for training machine-learning models, or for more heuristic one-off projects. I'll try to get more educated on the topic, and hopefully give more information in the coming weeks.

In T233595#5558130, @Niharika wrote:

Thanks for the explanation, @dbarratt and @Tchanders. Is there a reason we want to change the existing behavior (hard 24 hours expiry)?

Follow up from https://gerrit.wikimedia.org/r/c/mediawiki/core/+/537099/1/includes/block/BlockManager.php#467

It looks like instances of RedirectSpecialPage and ActionRaw are not getting the block cookies. For RedirectSpecialPage I'm not sure this is an issue because the user will get the cookies after the redirect is complete. For ActionRaw it looks like it sets its own headers rather than using OutputPage, perhaps a new task should be created for one or both of these issues.

In T233594#5555784, @dom_walden wrote:

For logged in users with autoblocks against their accounts

In T234765#5554309, @Nwmcsween wrote:

I followed the docker hub install method which is the "Using on a single web server" method, also sort of related mediawiki log errors don't/won't propagate out from the container (even when setting logfile to /dev/stdout) making debugging this really really hard

I added a step on using Composer to download the PHP dependencies (if that is what the problem is): https://www.mediawiki.org/wiki/Docker/Hub#Using_for_MediaWiki_Development

Which instruction did you follow? I just realized if it's the dev instructions I forgot to include that composer install needs to be run.

@Tchanders Is there a patch for this? (sorry I went to this in the opposite direction)

In T231577#5548063, @Niharika wrote:

@dbarratt This task is more like a "rolling task" for deploying Special:Mute everywhere. It is only on betas and testwiki for now.

Doesn't the cookie expire anyways?

I actually don't see why this option should even be availble if you have $wgBlockDisablesLogin enabled.... I propose we disable the field completely... unless @Tchanders or @dmaza can think of a use case where autoblocks would be used under that condition?

This seems like a duplicate of T217363 ?

In T196575#5495720, @daniel wrote:

Together with @Krinkle I'm currently trying to figure out how to make this kind of thing work without global state.

In T232176#5488888, @Anomie wrote:

Also that would mean we'd be requiring registration for anyone to be able to use the REST API. Anons would be locked out.

Errr.. ok, we would need Access-Control-Allow-Headers: Authorization :)

In T232176#5488416, @Bawolff wrote:

My reading of that, combined with "A CORS non-wildcard request-header name is a byte-case-insensitive match for Authorization." would be that allow-credential just affect browser managed credentials, and if you explicitly put Authorization in the allowed headers (must be explicit, it is not included with a wildcard), then you can override the value of the Authorization header.

In T232176#5488383, @Bawolff wrote:

But if your authentication is coming from an Authorization header, and no cookies are involved, the Access-Control-Allow-credentials would have no effect, as that only controls browser level credentials (cookies, TLS certs, http basic auth, etc)

In T232176#5488359, @Bawolff wrote:

So in this scenario, if we're using solely the authorization header and no cookies (And i presume using our own authorization header, not HTTP basic auth or anything like that), why would we need Access-Control-Allow-credentials?

In T232176#5488296, @Bawolff wrote:

I'm confused. Are you talking about setting Access-Control-Allow-Credentials: true when Access-Control-Allow-Origin: *. My reading of https://fetch.spec.whatwg.org/#cors-protocol-and-credentials is that that is banned in the spec.

@Bawolff I realized above, that I was conflating two different things (storage of the sessions and how the session token is transmitted to the server). What I mean is this:

Ok, let me rephrase this in the context of this task...

In T232692#5488126, @Isarra wrote:

So what's the specific problem with regard to MediaWiki? Is this blocking something? Would it enable us to do something of particular value in our contexts here?

In T196575#5472917, @Krinkle wrote:

That assumes all MW code paths are allowed to set cookies and that something else will take responsibility for disabling Cache-Control. I suspect neither is the case, but I haven't yet tried to confirm this.

In T232692#5486662, @MZMcBride wrote:

The problem section doesn't explain what's problematic. It describes the current situation, where we keep sessions server-side and centralized. What's the problem with this approach?

I created a task for discussing making MediaWiki unaware of the logged in status of its users: T232692

In T232176#5484153, @Anomie wrote:

If you don't vary on Origin, then what prevents a response to a request from a whitelisted origin (or a non-CORS request, for that matter) from being cached and served to a request from a non-whitelisted origin?

I moved this onto the development board too eagerly. This needs product input from @Niharika. :)

Related to CSRF tokens on stateless authentication: T126257

In T232176#5479884, @Anomie wrote:

I don't know what "authentication profiles" means. I do know that the current plan seems to be for the core REST API to use the same SessionManager sessions as the rest of MediaWiki rather than trying to reinvent everything.

In T196575#5472917, @Krinkle wrote:

Calling trackBlockWithCookie() as standard part of pre-shutdown on web requests

@Mainframe98 would you mind updating the task description? I don't think it reflects the solution you've implemented. :)

I created this task as per requested in https://www.mediawiki.org/wiki/Topic:V5y8azvepfpwyfdx