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.
@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
Now having trouble using a config file for login with safe auth login --self-auth -c ~/.safe/test
I tried
thephrase
theword
and also
passphrase=thephrase
password=theword
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
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…?..
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.
So how about making self-auth the default and something like --no-auth / --no-self-auth / other? for disabling the default self authorisation behaviour?
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.
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.
