Unable to upload files with SAFE CLI - Failed to decode the credentials: InvalidMsg

I’ve updated safe CLI (safe update) and the auth daemon (safe auth update && safe auth restart) added the shared vault config and selected it (safe networks switch shared).

Then I created an account, authorised the CLI and am trying to upload some files but get an error:

safe files put -r dist/
[2020-02-11T13:33:23Z ERROR safe] safe-cli error: Failed to connect: [Error] InvalidInput - Failed to decode the credentials: InvalidMsg

I may well have missed something obvious. I followed the instructions in the SAFE CLI Guide up to this point, so not sure what I’m doing wrong.

OS: Ubuntu 19.04

$ safe --version
safe-cli 0.8.1

$ safe auth status
Sending request to authd to obtain an status report...
| SAFE Authenticator status                |       |
| Authenticator daemon version             | 0.0.4 |
| Logged in to a SAFE account?             | Yes   |
| Number of pending authorisation requests | 0     |
| Number of notifications subscribers      | 0     |

Have you logged in again with --self-auth ? perhaps CLI is trying to use some old/invalid credentials, perhaps credentials you have for a local vault you were previously using?

Edit: I see you said you created a new account and authorised CLI, so it seems that’s the answer to my Q, I’ll give it a try with shared vault in the meantime.

1 Like

@happybeing, I just created an account and then logged in with --self-auth and I was able to upload files.
Can you please make sure (or try again if you did it already) you login and self-authorise CLI with the new account?:
$ safe auth login --self-auth


That sorted it thanks Gabriel. I’m not sure what I did to end up using old credentials, but it works now :smile:


Now having trouble using a config file for login with safe auth login --self-auth -c ~/.safe/test

I tried


and also


But both give the error:
[2020-02-11T15:04:35Z ERROR safe] safe-cli error: Format of the config file is not valid and couldn't be parsed: expected value at line 1 column 1

That has to be in a json format like it used to be for the old safe-auth CLI, e.g.:

{ "passphrase": "thephrase", "password": "theword" }

Thanks. I’ve added an issue to document this in the --help usage and CLI user guide: issue #419


Thanks, a PR would be welcome too :wink:


@bochaco is there any reason that --self-auth should not be made the default for safe-cli?

The way I saw it was that it could be the case you are simply managing one/multiple remote Authenticator daemons with CLI (note there is an --endpoint optional arg) and not necessarily trying to use CLI for manipulating data with an account, i.e. using CLI only to administer/manage authd. So let’s say you login but you then use some other app to manipulate data with it (similar to current state of SNAPP), presumably trying to not store credentials where you are not using them…?..

@bochaco so people seem to keep bumping into this as a head scratcher/friction. myself included.

A few questions I would ask are:

  1. What is the most common use-case for a CLI user now?
  2. What will be the most common use-case for a CLI user in the future?
  3. Can the situation be auto-detected by the software, so that the default can be ‘auto’ or not even need a flag?

and my answers today would be:

  1. A developer or very early adopter running a single vault and single authd, that needs to use --self-auth every time.
  2. I’m not certain, but still likely a single authd scenario.
  3. I don’t know. ask @bochaco.

defaults are about the principle of least surprise and just working for people unless they need to do something out of the ordinary.

So I think that could mean making --self-auth the default now, and it could be changed to something else later if/when the most common use-case changes.


That would probably be my answer too, in general, if we all believe this is the best thing then we can do it.


I would support this change.


So how about making self-auth the default and something like --no-auth / --no-self-auth / other? for disabling the default self authorisation behaviour?

1 Like

Is the --self-auth flag only ever used with safe auth login?

1 Like

Yes, correct, that’s how it currently is at least. There is also another thing we could change/enhance if it’s confusing, when you create an account authd stays logged with that new account, but CLI is not self-authorised with that new account at that point…so…thoughts?

Edit: one more for consideration, we could also transform the $ safe auth into a self-authorisation one, with same flag as above to disable the default.

1 Like

I’m not sure that “self Auth” really makes sense as a concept. As I understand it: it’s actually dealing with the storing of local credentials, perhaps the argument wording could change to reflect that?

OK just so I’m clear, at the moment safe auth login --self-auth both logs the user in and also authenticates the CLI, whereas safe auth sends a request to the authenticator to authenticate the CLI which must then be approved manually with safe auth allow <code> .

Is there any reason why you would not want to authenticate the CLI when you login via the command line?

Exactly! this is the answer to your comment also @Shane, CLI is just another app which needs to be authorised by the user. For convenience we have the self-auth, but it’s argued now that’s probably the common use case therefore do it automatically for CLI.

The reason why safe auth cmd didn’t have the self-auth option is because eventually we’ll secure the comm between CLI/SNAPP and authd, so only the instance which logged in to an account can also authorise apps, otherwise any app could connect to the authd and self auth. So there are plans to provide a token back to the CLI/SNAPP when the user logs in, only with that token other operations will be accepted by authd, like allow auth reqs.

For now apparently that’s not a common use case, as discussed above with @danda, so that’s why this is all being suggested.


Ah, this was the missing bit of the puzzle! My next question was going to about the options for apps to self-authenticate and how that would be controlled. I suppose for now it just depends on how much work it is to switch to temporarily self-auth being the default. As @danda suggests, this is certainly likely to be the most common use case for now, whereas in future the vast majority of users will use an app with a GUI. If it’s a lot of work probably not worth it (although I can’t comment on the degree of friction developers are finding), but if it’s relatively quick with no side effects, then it makes sense to change, at least to me.