Support multiple backends from the CLI

[dcastro]

This issue depends on #15.

Right now, the CLI assumes there's only 1 backend. It will need to be refactored to allow the user to specify which backend they want to interact with.

@MagicRB has suggested the following syntax:

coffer view mybackend#some/path

[DK318]

Maybe it would be better to have syntax like this?

coffer #mybackend view some/path

Because it is not clear how to support this for e.g. find command.

[balsoft]

coffer #mybackend view some/path

This won't work in almost any modern shell, a space followed by a hash (#) starts a comment.

[Heimdell]

-b mybackend or --backend mybackend?

[Heimdell]

Or coffer view /backend/some/path, a la "absolute path"

[MagicRB]

Why not coffer find backend# search_term? Or even drop the # so just coffer find backend search_term, if we do the former we can also easily restrict the find to some subfolder.

[MagicRB]

Or coffer view /backend/some/path, a la "absolute path"

I think that avoiding paths that look like filesystem path but aren't filesystem path us for the best.

[Heimdell]

I suggest that we either use shell and don't do risky stuff or make it a repl-like and do whatever we want.

[MagicRB]

Well nix uses essentially the same syntax i proposed and its fine imo

[dcastro]

Looks like we have two options, either specify the backend as a separate argument (-b mybackend) or as part of the path argument (backend#path, backend/path, etc.)

I think there's a question we need to consider first, and I believe the answer will lead us down the right path:

Do we want to allow users to copy/move entries from one backend to another?

Remember that the copy/rename commands take two paths as arguments.

So if we want to allow copying/renaming from one backend to another, then I think specifying the backend in the path would be more ergonomic:

coffer copy vault#/some/path pass#/other/path

If we don't want to allow users to do this, then -b makes more sense:

coffer copy -b vault /some/path /other/path

I think we should allow users to do this (I don't see a reason not to). What do you all think? /cc @notgne2

[MagicRB]

Personally, as a future user, I really need to be able to copy between backends. I use pass for my own personal secrets but Vault for machine secrets (I utilize HashiCorp Nomad and Consul) so having the ability to quickly copy a secret from one to the other is really desirable for me. Especially since we managed to retain at least read-only compatibility with normal Vault tooling.

[dcastro]

Regarding backend#path vs backend/path, again I think it boils down to this:

I think we don't want the user to have to specify a backend all the time. They should be allowed to specify a "default backend" in the config. When a command is invoked and the backend is not specified, then the "default backend" is used.

So if that's the case, then backend/a/b would be ambiguous. Did the user mean "The path a/b in the backend backend", or did they mean "the path backend/a/b in the default backend"?

For that reason, I think a separate syntax (like a # suffix) for the backend segment is needed.

Why not coffer find backend# search_term?

Agreed.

Or even drop the # so just coffer find backend search_term, if we do the former we can also easily restrict the find to some subfolder.

I disagree with this bit. Dropping the # suffix would make "backend" ambiguous, as I mentioned above.

[MagicRB]

So maybe backends would always be suffixed with backend#, even in the TUI to really engrain into the users brain that in fact yes they have to use the # at the end everywhere. Except for the config file, id leave that without but the cli and webui should follow this logic imo.

[DK318]

Maybe it would be better to support both variants? (-b|--backend and separating backend name with hash)

[dcastro]

Maybe it would be better to support both variants?

Is there a need to support both?

Keep in mind that supporting two ways of doing the same thing has a cost too. 1) the cost of maintenance for us developers, and 2) the cost of a more complex UX/steeper learning curve for the users.