Differential D19935 Diff 47692 resources/sql/autopatches/20181228.auth.01.provider.sql

Changeset View

Standalone View

				CREATE TABLE {$NAMESPACE}_auth.auth_factorprovider (
				id INT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
				phid VARBINARY(64) NOT NULL,
				providerFactorKey VARCHAR(64) NOT NULL COLLATE {$COLLATE_TEXT},
				status VARCHAR(32) NOT NULL COLLATE {$COLLATE_TEXT},
				amckinleyUnsubmitted Not Done Inline Actions Maybe this should be `UNIQUE`? amckinley: Maybe this should be `UNIQUE`?
				epriestleyAuthorUnsubmitted Done Inline Actions I think it's conceptually okay to have multiple factors for the same provider. For example, maybe two different subgroups at your org set up Duo independently, and then you adopt Phabricator, and then everyone realizes no one was talking to each other. So you configure both Duo accounts and call one "Ops Duo (Use This One)" and one "Eng Duo (Deprecated, Do Not Use)" and then move toward merging them, but everything works as-is for now and you don't need to transition half the org on day one. (Or you have a 128-bit TOTP source and a 256-bit TOTP source and move from one to the other, perhaps.) Most of the uses I can come up with are around gracefully transitioning between providers, but this kind of "one old version, one new version" smooth transition seems pretty reasonable. epriestley: I think it's conceptually okay to have multiple factors for the same provider. For example…
				properties LONGTEXT NOT NULL COLLATE {$COLLATE_TEXT},
				dateCreated INT UNSIGNED NOT NULL,
				dateModified INT UNSIGNED NOT NULL
				) ENGINE=InnoDB, COLLATE {$COLLATE_TEXT};