Once https://gerrit.wikimedia.org/r/#/c/213764/ is merged, all wikis can use a single db table for storing credentials (much like CentralAuth does for passwords, etc).
It seems logical to add this table to the existing centralauth database.
The schema is extremely simple:
CREATE TABLE /*_*/oathauth_users ( -- User ID id int not null primary key, -- Secret key secret varbinary(255) null, -- Scratch tokens scratch_tokens varbinary(511) null ) /*$wgDBTableOptions*/;
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| Set oathauth_users as a private table | operations/puppet | production | +1 -0 |
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | • dpatrick | T107605 Support two-factor authentication on CentralAuth wikis | |||
| Resolved | • csteipp | T130700 Create central OATHAuth table for CentralAuth wikis |
@jcrespo, is there any issue with me creating this on the centralauth db master? Or is that something you need to do?
As per https://wikitech.wikimedia.org/wiki/Schema_changes#What_is_not_a_schema_change :
Creating new tables. This is not a dangerous process, and can be done unattended, although if new tables are introduced for all wikis, you should CC a DBA.
It would be nice, however, to add the required changes to software/redactatron for labs.
From a security perspective, do we want to keep the oath secret data on the same database as password hashes? Or should it live somewhere else (similar to extension1 or something)?
Both will be separated out with T120484. Until then, I'm happy to put it wherever makes sense.
It would be nice, however, to add the required changes to software/redactatron for labs.
@chasemp, who's the best person who could point to where/what needs to get updated for that?
@chasemp, that would be great if I could get some help with this. I think I could add each column to cols.txt, but I'd rather the entire table was just blacklisted from being replicated.
I'm also not sure the order of creating the table on the cluster, and committing a change there, since I think the script would break if it's committed before the table is created, right?
I've scheduled time on May 18th to create the table, and enable the extension (only accessible to a few people).
https://wikitech.wikimedia.org/w/index.php?title=Deployments&type=revision&diff=512849&oldid=512677
@jcrespo, if that's a bad time for me to be adding the table on the centralauth db, let me know and I can reschedule.
Once the table is actually in place (and only has a limited amount of test data), I think I can add/test the redactatron entries to keep it out of labs.
@jcrespo If the table should not be in labs, ping me so I can check the replication filters. What is the shard and name of the table?
I am blocking this until I am sure this is safe. Hopefully I can do it before the planned date.
Change 288897 had a related patch set uploaded (by Jcrespo):
Set oathauth_users as a private table
This is a horrible commit that I am doing and it should make you aware of how badly things are regarding filtering. I have commented on T103011#2296587 to try to raise awareness of how bad this is. And we should do T120484 ASAP.
Mentioned in SAL [2016-05-16T11:20:05Z] <jynus> testing create table on s7-master T130700
Filters have been modified and I have even tested creating and dropping the above table. I am no longer a blocker of this table creation.
Given the current state of things I will change https://wikitech.wikimedia.org/wiki/Schema_changes#What_is_not_a_schema_change to reflect I am a blocker on creating new tables, too, until labs workflow gets better.
mysql:wikiadmin@db1041 [centralauth]> CREATE TABLE `oathauth_users` (
-> `id` int(11) NOT NULL,
-> `secret` varbinary(255) DEFAULT NULL,
-> `scratch_tokens` varbinary(511) DEFAULT NULL,
-> PRIMARY KEY (`id`)
-> ) ENGINE=InnoDB DEFAULT CHARSET=binary;
Query OK, 0 rows affected (0.06 sec)The table showed up on slaves, so creation replicated without a problem.