In the authentication section of the getting started doc, the token used
to login doesn't match with the one displayed as the command result.
This commit makes sure that both tokens correspond to avoid distracting
newcomers.
This removes all references I could find to:
- credential provider
- authentication backend
- authentication provider
- auth provider
- auth backend
in favor of the unified:
- auth method
Using the latest vault release, I was getting the following error when the policy used `write`:
Error: Error making API request.
URL: PUT http://0.0.0.0:8200/v1/sys/policy/secret
Code: 400. Errors:
* Failed to parse policy: path "secret/*": invalid capability 'write'
I think `create` is the correct new Capability.
Looks like the `500` is now a `405`:
```
$ vault read aws/config/root
Error reading aws/config/root: Error making API request.
URL: GET http://127.0.0.1:8200/v1/aws/config/root
Code: 405. Errors:
* 1 error(s) occurred:
* unsupported operation
```
One thing that has been a point of confusion for users is Vault's
response when deleting a key that does not actually exist in the system.
For example, consider:
$ vault delete secret/foo
Success! Deleted 'secret/foo'
This message is misleading if the secret does not exist, especially if
the same command is run twice in a row.
Obviously the reason for this is clear - returning an error if a secret
does not exist would reveal the existence of a secret (the same reason
everything on S3 is a 403 or why GitHub repos 404 instead of 403 if you
do not have permission to view them).
I think we can make the UX a little bit better by adding just a few
words to the output:
$ vault delete secret/foo
Success! Deleted 'secret/foo' if it existed
This makes it clear that the operation was only performed if the secret
existed, but it does not reveal any more information.
