@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?
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)?
Sat, Oct 12
@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?
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).
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. :)
Fri, Oct 11
Thu, Oct 10
Wed, Oct 9
Tue, Oct 8
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.
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
Sun, Oct 6
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.
Sat, Oct 5
@Tchanders Is there a patch for this? (sorry I went to this in the opposite direction)
Fri, Oct 4
Wed, Oct 2
Tue, Oct 1
Doesn't the cookie expire anyways?
Thu, Sep 26
Thu, Sep 19
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?
Wed, Sep 18
This seems like a duplicate of T217363 ?
Mon, Sep 16
Sep 12 2019
Errr.. ok, we would need Access-Control-Allow-Headers: Authorization :)
@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...
I created a task for discussing making MediaWiki unaware of the logged in status of its users: T232692
Sep 11 2019
I moved this onto the development board too eagerly. This needs product input from @Niharika. :)
Sep 10 2019
Related to CSRF tokens on stateless authentication: T126257
Sep 9 2019
Sep 6 2019
@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