Maybe implement PhabricatorAuthProviderConfigEditor->validateTransaction()?

This should more or less be available as either:

• ...Editor->validateAllTransactions(): easiest approach, but not ivory-tower-modular since extensions can't do anything about it. Probably the right approach here.
• ...Editor->validateTransactionsWithExtensions(), which you actually add code to by implementing a PhabricatorEditorExtension. This is ivory-tower-modular in the sense that it can do something like this:

if ($xaction instanceof TransactionWhichCaresAboutAuthLockInterface) {
  if (is auth locked) {
    raise validation exception;
  }
}

So it would let third-party code (a) implement Auth transactions which bypass this setting and (b) implement transactions in other applications which respect this setting.

I think the extreme modularity here has no actual driving use cases and validateAllTransactions() is probably the better fit.

Let me actually read the rest of the change, now...

I think some variation of this probably remains desirable no matter what, since we want to roadblock users before they start doing edits, not only once they reach the transaction layer -- not for correctness, but just for usability, so they don't fill out a form and then learn that their changes can't be saved.

The "full correctness" change is probably:

• optionally, modularize these transactions;
• use Editor->validateAllTransactions() to implement this check at the transaction layer so future API callsites and such can't bypass it.

I was also looking for a way to still render the form, except with all the fields grayed out, since it isn't terribly user-friendly to make someone unlock the config just to see what it already says. This seems tricky though, since there's no AphrontFormView->getChildren() method I can iterate over to call setDisable(true) on.

I'd like to make the "view" page more useful (/auth/config/view/X/) which will probably solve that (by showing the non-secret configuration parameters before you hit the edit screen). That page is somewhat recent and just hasn't really been built out yet.

I'm also imagining possibly moving the common behaviors ("Can register / login / link / unlink") to a separate form since you rarely need to fiddle with them, they're pretty wordy, and they make the "Edit Provider" form huge even for providers that need relatively little configuration.