Things my team is working on: MediaWiki-Platform-Team
Side projects I am working on (or planning to, eventually): User-Tgr
You can find more info about me on my user page.
User Details
- User Since
- Sep 19 2014, 4:55 PM (495 w, 3 d)
- Availability
- Available
- IRC Nick
- tgr
- LDAP User
- Gergő Tisza
- MediaWiki User
- Tgr (WMF) [ Global Accounts ]
Fri, Mar 15
Database::query() uses QueryBuilderFromRawSql::buildQuery() to convert raw SQL strings to query objects, and that method will always add either QUERY_CHANGE_NONE or QUERY_CHANGE_ROWS. But that stack trace doesn't match that happening - Database::query() already receives a Query object, somehow. Manually overriding the flags might paper over the problem, which might not be the best approach here. What if the Query object is corrupted in other ways as well?
Thu, Mar 14
The logic of handling an SQL string in Database::query() looks solid to me, but...
#2 /srv/mediawiki-staging/php-master/includes/libs/rdbms/database/DBConnRef.php(119): Wikimedia\Rdbms\Database->query(Object(Wikimedia\Rdbms\Query), 'ExternalStoreDB...', 8) #3 /srv/mediawiki-staging/php-master/includes/libs/rdbms/database/DBConnRef.php(302): Wikimedia\Rdbms\DBConnRef->__call('query', Array) #4 /srv/mediawiki-staging/php-master/includes/externalstore/ExternalStoreDB.php(266): Wikimedia\Rdbms\DBConnRef->query('-- Blobs table ...', 'ExternalStoreDB...', 8)
...it looks like a query string is transformed into a Query object in the process of a simple call proxying, and Database::query() is already receiving an object (presumably with invalid flags)? No idea what's going on there.
Wed, Mar 13
I don't think a test site would have much point.
Usually origin trials are disabled for a given site after reaching 0.5% of all Chrome pageloads; it seems unlikely but not completely inconceivable that Wikipedia would reach this threshold. But, if I understand the documentation correctly, this restriction doesn't apply for deprecation trials, only trials of new features, so we don't need to worry about it.
There are two third-party cookie blocking deprecation trials:
- A first party trial where we could register a top-level domain such as wikipedia.org and third-party cookie access is allowed as long as the top-level document's domain is a subdomain of that. Enabling the trial happens via an Origin-Trial HTTP header or a corresponding meta tag on the embedding page.
- A third-party trial where we can register a third-party domain and then it can be used anywhere. The documentation is a bit confusing on this point but AIUI you we can either use a header or meta tag on the embedded page, or use JS to add a meta tag to the embedding page. (The generic origin trial docs include this somewhat confusing warning: "Caution: A third-party token must be provided in an external JavaScript file included via a <script> element: a third-party token won't work in a meta tag, inline script or HTTP header.") Whether the trial will be declared on embedding or embedded pages needs to be declared up ahead; if we want both, we need to register twice.
Tue, Mar 12
Enrolling requires filing a bug about the website being affected, so here it is: https://issuetracker.google.com/issues/329250103
Next step is to test the relevant browser APIs:
Back when I looked at requestStorageAccessFor, it was still in development. Now caniuse says it's available, but only works between sites of the same RWS set. So it might not be relevant for this task at all.
Improved the inline docs a little. (Note that the message changed, it is now Session "{session}": the session store entry is for an anonymous user, but the session metadata indicates a non-anonynmous user.) I have two hypotheses of what could be happening:
- When the user logs out, the login cookies do not get unset for some reason, so the user is left with an anonymous session (is this actually true? do we set the backend session to anonymous on logout, rather than deleting it?) but logged-in cookies. I don't think this explains what's going on, given how frequent the logs are, and failing to unset cookies isn't something that should happen often.
- When the user logs out on CentralAuth, cookies on domains other than the current one are left in place (T143001: Wiki sites should delete all their cookies during logout). I don't think this would result in this message (those domains would have no session or an invalid logged-in session, not an anonymous session) but maybe I misremember the details of how CentralAuth session invalidation on login works.
Relevant (but outdated) description from the parent task:
Use the requestStorageAccess() or requestStorageAccessFor() API, which allow access to third-party cookies. (requestStorageAccess is better supported, but needs to be called by the embedded resource, so it's only usable for iframes; requestStorageAccessFor is called by the embedder.) These would probably be part of using first-party sets, but can be used without those as well; however, then they would require explicit user opt-in (and separately for each domain), making them less practical. Also, they can only be called after user interaction.
support: requestStorageAccess (caniuse) is supported in Firefox and Safari, supported but requires first-party sets in Edge, behind a feature flag in Chrome. requestStorageAccessFor is Chrome-only (chromestatus).
Undeployment is hard because you need to convert the existing content but switching Flow to readonly on a given wiki should be trivial, if there is community support for it (except someone would have to move all the Flow pages afterwards to make place for wikitext comments).
Mon, Mar 11
For the record, the exact stack trace is
Wikimedia\Rdbms\DBConnectionError from line 1123 of /vagrant/mediawiki/includes/libs/rdbms/loadbalancer/LoadBalancer.php: Cannot access the database: Unknown database 'virtual' (127.0.0.1) #0 /vagrant/mediawiki/includes/libs/rdbms/loadbalancer/LoadBalancer.php(779): Wikimedia\Rdbms\LoadBalancer->reportConnectionError() #1 /vagrant/mediawiki/includes/libs/rdbms/loadbalancer/LoadBalancer.php(767): Wikimedia\Rdbms\LoadBalancer->getServerConnection() #2 /vagrant/mediawiki/includes/libs/rdbms/database/DBConnRef.php(103): Wikimedia\Rdbms\LoadBalancer->getConnectionInternal() #3 /vagrant/mediawiki/includes/libs/rdbms/database/DBConnRef.php(117): Wikimedia\Rdbms\DBConnRef->ensureConnection() #4 /vagrant/mediawiki/includes/libs/rdbms/database/DBConnRef.php(351): Wikimedia\Rdbms\DBConnRef->__call() #5 /vagrant/mediawiki/includes/utils/BatchRowIterator.php(248): Wikimedia\Rdbms\DBConnRef->select() #6 /vagrant/mediawiki/includes/utils/BatchRowIterator.php(206): BatchRowIterator->next() #7 /vagrant/mediawiki/extensions/AntiSpoof/maintenance/BatchAntiSpoofClass.php(94): BatchRowIterator->rewind() #8 /vagrant/mediawiki/maintenance/includes/MaintenanceRunner.php(698): BatchAntiSpoof->execute() #9 /vagrant/mediawiki/maintenance/run.php(51): MediaWiki\Maintenance\MaintenanceRunner->run() #10 /var/www/w/MWScript.php(99): require_once('/vagrant/mediaw...') #11 {main}
Sun, Mar 10
Just filter to logged-in pageviews. I think we already do that somewhere, there just isn't any public export of the data.
No idea if this is a bug with Vagrant or composer itself. Vagrant doesn't reference composer/pcre at all.
Sat, Mar 9
Those were added in https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/264437 and I'm pretty sure they were meant to be temporary.
(Couldn't find any analytics-related project that isn't specific either to some software component or to some WMF management process, so tagging WMF-General-or-Unknown.)
Thu, Mar 7
It's listed in T290790: Group OAuth grants by riskiness as such but looks like I forgot to make an actual patch for it.
Wed, Mar 6
The tool is still generating uploads.
Tue, Mar 5
Since this was reported in 2020 June and Safari rolled out third-party cookie blocking beginning 2020 March, it was very likely caused by that feature, which is already covered by several other tasks and has been somewhat improved since. So let's close this.
System blocks are not stored in the database (or, if you want, the de facto storage mechanism would be the global user registration date field in this case). Using the authentication state as storage mechanism instead would be probably possible too.
Mon, Mar 4
@Bugreporter I filed T359116: Split up CentralAuth into smaller extensions about splitting up CentralAuth.
Note there is a similar (but different in terms of mechanics) problem with system users: T214722: Introduce global system users / T111686: Add new accounts used by extensions to SUL / T275931: Have new MassMessage system users be automatically attached to CentralAuth.
I think the easiest way to do this would be T359064: Represent temporary account expiry with system blocks.
Somewhat belatedly, I thought of what seems like a better method (although maybe somewhat complementary): T359064: Represent temporary account expiry with system blocks
In hindsight a better way to do this would be T359064: Represent temporary account expiry with system blocks (and then some version of T358979: Show global block information on Special:CentralAuth/<username>).
Per T334940#9537862, this will not be worked on in the context of the Graph extension. I think it's still meaningful in the wider context of T169027: Provide iframe sandboxing for rich-media extensions (defense in depth) so we can leave the task open.
Per T334940#9537862, not happening.
So apparently the old parser HTML doesn't have an empty row, the Parsoid HTML does have an empty row but it's invisible (as an empty <tr> should be) and VisualEditor inserts an "add cell" affordance (implemented as a <td>) so the row is not empty anymore.
I suppose that would require some sort of hook for adding information snippets to Special:CentralAuth. At which point I wonder if we should rename it to something less extension-specific (like CentralUser)?
Extensions aren't enabled when the installer runs and creates the admin account. Vagrant migrates the admin user manually; other environments could do that, or I guess we could create some sort of post-install hook that the installer calls as a final step.
Sun, Mar 3
Wed, Feb 28
Use shell.php and check what kind of object is returned by ObjectCache::getInstance( $wgSessionCacheType ).