luxolus/open-consul
2
0
Fork 0
Code Issues 1 Pull requests Packages Releases Wiki Activity

website: Document new ACL upsert behavior

Browse source
This commit is contained in:
Armon Dadgar 2015-05-05 19:25:27 -07:00
parent b0fb010c2d
commit 0473b40df2
1 changed files with 6 additions and 2 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

8
website/source/docs/agent/http/acl.html.markdown
View file

@ -54,6 +54,10 @@ None of the fields are mandatory. In fact, no body needs to be PUT if the
defaults are to be used. The `Name` and `Rules` fields default to being
blank, and the `Type` defaults to "client".
The `ID` field may be provided, and if omitted a random UUID will be generated.
The security of the ACL system depends on the difficulty of guessing the token.
Tokens should not be generated in a predictable manner or with too little entropy.
The format of the `Rules` property is [documented here](/docs/internals/acl.html).
A successful response body will return the `ID` of the newly created ACL, like so:
@ -69,8 +73,8 @@ A successful response body will return the `ID` of the newly created ACL, like s
The update endpoint is used to modify the policy for a given ACL token. It
is very similar to the create endpoint; however, instead of generating a new
token ID, the `ID` field must be provided. As with [`/v1/acl/create`](#acl_create),
requests to this endpoint must be made with a management
token.
requests to this endpoint must be made with a management token. If the ID does not
exist, the ACL will be upserted. In this sense, create and update are identical.
In any Consul cluster, only a single datacenter is authoritative for ACLs, so
all requests are automatically routed to that datacenter regardless