[Suggestion] Locally install script for disabling 2FA

[drmrbrewer]

With two factor authentication enabled, there is a risk that we cannot access our instance if pro.caprover.com is down. It's relatively easy to revert to non-2FA by running a script as described here.

But rather than having to seek out this help page, create and run this script (maybe not so easy for those with more limited knowlege, and what happens if caprover.com is also down?), my suggestion is to install this "reset OTP" helper script locally when installing caprover, so it's then just a case of running that script directly when needed. Either in some bin folder that is already in the PATH or even just in /captain/scripts or somewhere like that.

Apparently it's not possible to disable 2FA via the CLI (because the CLI talks to the server through the API which requires authentication, which in turn requires 2FA... so when 2FA is down, CLI authentication also fails)... but could the CLI command (e.g. caprover disable2fa) just be a shortcut to run the local script itself (rather than trying to talk to the server as such)?

[githubsaturn]

Thanks! A new helper script is added: (added in 1.12+)

docker exec -it $(docker ps --filter name=captain-captain -q) npm run disable-otp

[drmrbrewer]

So that’s the command we will need to run? Is it not possible to wrap it all up into a single script so that we just call that? Or is it not possible to use a cli command as a shortcut to run the script, as suggested in the OP… that is at least more visible to the user?

[githubsaturn]

For the shortcut solution, one had to install the cli on the server... Much bigger headache than this single line.

And no, unfortunately I cannot think of a better way to do this. Keep in mind this is an extreme case where the 3rd party server is down and you don't have a valid auth key. So it's not a command that you'll use frequently.

[drmrbrewer]

Isn’t the CLI already installed on the server? At least, it is for me. I was just thinking it would be neat to have a solution that didn’t require looking anything up, or any/much knowledge of the underlying Docker commands, which is after all what CapRover excels at.

[githubsaturn]

No the CapRover CLI tool is supposed to be installed on your local machine.

Yea I see your point, but in this case, this can't get any simpler. We could add a hint on login page if the Pro servers are down and point to this script...

[drmrbrewer]

CapRover CLI tool is supposed to be installed on your local machine

Ah, of course. I forgot that it's installed on my main server because I have a cloud-init script which installs everything required on this server, including restoring all data required from backup, also including restoring CapRover config and also deploying all apps using the CapRover CLI. So in my case I suppose that my main server is both a local machine (at least for the initial deploy) and the main CapRover instance. One of the apps installed on spin-up of the server is my IDE, and it is that which acts as my actual local server. But all on the same server!

Anyway, perhaps I'm showing my lack of understanding of shell scripts, but why can't you create an executable script file called caprover-disable-2fa with the following content:

#!/bin/bash
docker exec -it $(docker ps --filter name=captain-captain -q) npm run disable-otp

And stick it in e.g. /usr/local/bin, i.e. somewhere in the user's PATH. That way, if a slightly uncertain user doesn't know what to do when they can't access their CapRover instance, they might first consider seeing if there is a caprover-related command they can run (enter caprover then tab tab) and this caprover-disable-2fa will show up as a self-explanatory option to run... voila.

This is probably something I would add to my own cloud-init script (i.e. to create such a visible and self-explanatory helper script to find and run when I'm panicking that I can't get into my CapRover instance), unless it's created as standard...

[githubsaturn]

And stick it in e.g. /usr/local/bin, i.e. somewhere in the user's PATH.

CapRover itself runs in a container, hence cannot add any scripts to the host filesystem.

[drmrbrewer]

CapRover itself runs in a container, hence cannot add any scripts to the host filesystem

OK but it does have access to /captain and therefore could at least put such a standalone script in e.g. /captain/scripts (as suggested in my OP)?

[githubsaturn]

This is where I disagree on whether this is the right long term approach. i.e., I don't think running /captain/script/disable-otp.sh is far easier than docker exec -it $(docker ps --filter name=captain-captain -q) npm run disable-otp

You'd still have to lookup the docs to know whether it sits. So it's just a matter of a longer copy-paste.

[drmrbrewer]

I don't think running /captain/scripts/disable-otp.sh is far easier than docker exec -it $(docker ps --filter name=captain-captain -q) npm run disable-otp

It is in the sense that the script is already there on the local machine, and you don't need to look anything up (possibly on a help site that is down)... it's just a case of remembering that there are some handy helper scripts in /captain/scripts/ (which isn't hard to do) and then seeing if there is one that does what you need... nothing to look up and nothing to copy/paste.

You'd still have to lookup the docs to know whether it sits. So it's just a matter of a longer copy-paste

IMHO the current implementation of this suggestion does just that... you still need to lookup the docs and you still need to copy/paste the command(s) from the docs... so there isn't really any benefit to the user in copy/pasting 1 line (new solution) vs copy/pasting 4 lines (previous solution).

Anyway, I'll add a pre-written script to my own set of handy helper scripts which I create when spinning up a new server, if it's only me who will find it useful.