gogrlx/nats-server
1
0
Fork 0
mirror of https://github.com/gogrlx/nats-server.git synced 2026-04-02 03:38:42 -07:00
Code Issues Packages Projects Releases Wiki Activity

Update to gnatsd/README.md fixing authorization section addressing issue #662 "_INBOX.>" permission

Browse Source 
[ci skip]
This commit is contained in:
ainsley
2018-05-22 14:41:04 -05:00
parent e453d78f4a
commit 523bddd328
1 changed files with 19 additions and 11 deletions
Download Patch File Download Diff File Expand all files Collapse all files

30
README.md
View File

@@ -521,9 +521,10 @@ For example:
authorization {
PASS: abcdefghijklmnopqrstuvwxwz0123456789
users = [
{user: alice, password: foo, permissions: $ADMIN}
{user: bob, password: bar, permissions: $REQUESTOR}
{user: joe, password: $PASS}
{user: joe, password: foo, permissions: $ADMIN}
{user: alice, password: bar, permissions: $REQUESTOR}
{user: bob, password: $PASS, permissions: $RESPONDER}
{user: charlie, password: bar}
]
}
```
@@ -545,7 +546,7 @@ authorization {
}
```
Here is an example authorization configuration that defines three users, two of whom are assigned explicit permissions.
Here is an example authorization configuration that defines four users, three of whom are assigned explicit permissions.
```
authorization {
@@ -557,6 +558,10 @@ authorization {
publish = ["req.foo", "req.bar"]
subscribe = "_INBOX.>"
}
RESPONDER = {
subscribe = ["req.foo", "req.bar"]
publish = "_INBOX.>"
}
DEFAULT_PERMISSIONS = {
publish = "SANDBOX.*"
subscribe = ["PUBLIC.>", "_INBOX.>"]
@@ -564,20 +569,23 @@ authorization {
PASS: abcdefghijklmnopqrstuvwxwz0123456789
users = [
{user: alice, password: foo, permissions: $ADMIN}
{user: bob, password: bar, permissions: $REQUESTOR}
{user: joe, password: $PASS}
{user: joe, password: foo, permissions: $ADMIN}
{user: alice, password: bar, permissions: $REQUESTOR}
{user: bob, password: $PASS, permissions: $RESPONDER}
{user: charlie, password: bar}
]
}
```
Since Alice is an ADMIN she can publish/subscribe on any subject. We use the wildcard “>” to match any subject.
Since Joe is an ADMIN he can publish/subscribe on any subject. We use the wildcard “>” to match any subject.
Bob is REQUESTOR and can publish requests on subjects "req.foo" or "req.bar", and subscribe to anything that is a response ("_INBOX.*").
Alice is a REQUESTOR and can publish requests on subjects "req.foo" or "req.bar", and subscribe to anything that is a response ("_INBOX.>").
Joe has no permission grant and therefore inherits the default permission set. You set the inherited default permissions by assigning them to the `default_permissions` entry inside of the `authorization` configuration block.
Charlie has no permissions granted and therefore inherits the default permission set. You set the inherited default permissions by assigning them to the default_permissions entry inside of the authorization configuration block.
Note that `_INBOX.>` subscribe permissions must be granted in order to use the request APIs in Synadia supported clients. If an unauthorized client publishes or attempts to subscribe to a subject, the action fails and is logged at the server, and an error message is returned to the client.
Bob is a RESPONDER to any of Alice's requests, so Bob needs to be able to subscribe to the request subjects and respond to Alice's reply subject which will be an _INBOX.>.
Important to note, NATS Authorizations are whitelist only, meaning in order to not break request/reply patterns you need to add rules as above with Alice and Bob for the _INBOX.> pattern. If an unauthorized client publishes or attempts to subscribe to a subject that has not been whitelisted, the action fails and is logged at the server, and an error message is returned to the client.
### TLS