Fixed in https://github.com/folio-org/stripes-core/commit/74ae13a6cce97962409dd4d67ae390198ca86e43

Added a note to that document, explaining that disableAuth is deprecated and noting that we need to write about how to establish authentication services. https://github.com/folio-org/ui-okapi-console/blob/master/doc/running-a-complete-system.md#disable-authentication

We still have a few people – I think is one – using disableAuth in their stripes.config.js to avoid having to engage with the permission system at all. That is going to become increasingly untenable as more and more operations are prohibited by permission checks, and especially when we implement which will prevent users from even getting into any of the applications.

We could slightly ameliorate that by changing hasPerm so it always returns true if disableAuth is on; but that won't really help because of course the back-end modules will reject the operations the UI requests, even if the UI is persuaded to make them.

So the question becomes: what is the transition path for people using disableAuth? I see three options.
1. Use the auth-blackbox VM. (This is what I do: it's great.)
2. Run against a hosted Okapi-and-modules setup. (Do we have one?)
3. Check out, build and run your own Okapi-and-modules setup.

I think #3 is too difficult to be a tenable option for most people – there are just too many ways for it to go wrong. We have a document on how to run a complete FOLIO system but that has been very much overtaken by subsequent developements, including the addition of all the authentication/authorization stuff, which it doesn't even touch on.

If we want #3 to be a realistic proposition, we will likely need someone to take that document on and own it – not me. Someone who is prepared to take responsibility to bringing it up to date and keeping it that way as things continue to change.