Technically: In theory, probably. In practice? Maybe more difficult.

I wouldn't like to guess whether the CentralAuth maintenance scripts for doing this (attaching accounts) still actually work properly, which is what is probably needed, if accounts are created standalone. Spending time debugging and fixing them probably isn't worth anyones time.

We certainly don't have a pattern of doing this setup currently with CentralAuth.

One idea would be... remove read from '*' and 'user' (as it's granted to both), use the usual $wgWhitelistRead to allow people to see the main page, login (which should create their account attached on CentralAuth, I think) etc but not actually view anything... And then manually add them to a user group that gives them 'read' the read permission again, if you want them to have access to the wiki.

Honestly cannot say how well that would work. Should be testable on beta though... Even with some accounts already existing (they'll just lose their read access)

Thanks, @Reedy! For context, our goal is to have a place to publish and iterate on API Portal content before launch, without it being publicly visible. Based on your answer, it seems like we could do this in one of two ways:

1. Store the content on api.wikimedia.org and manipulate the permissions scheme (as described above) so it would only be viewable to certain users until launch. We'd need to verify that this is possible to do by testing on beta.
2. Store the content on api.wikimedia.beta.wmflabs.org, and import the content to api.wikimedia.org for launch using Manual:Importing_revisions. This requires adding me as a docseditor on api.wikimedia.beta.wmflabs.org.

It seems like option 2 is the simpler choice, but I'd love to hear your thoughts.

Option 2 doesn't solve the problem of the work not being publicly visible.

The beta cluster wikis are as open as production ones. So we'd have apply the similar rights there too to get any sort of privacy.

And then more people have shell access to the wikis too...

Also, while the beta cluster isn't likely to lose any data, it's not guaranteed. We don't do backups etc

I can certainly grant you docseditor either way on the beta api wiki.

Option 2 doesn't solve the problem of the work not being publicly visible.

Good point :)

One idea would be... remove read from '*' and 'user' (as it's granted to both), use the usual $wgWhitelistRead to allow people to see the main page, login (which should create their account attached on CentralAuth, I think) etc but not actually view anything... And then manually add them to a user group that gives them 'read' the read permission again, if you want them to have access to the wiki.

This sounds like a great approach. I'll add this to T249834 as a separate section. Thanks again!