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

Update based on code review

Browse Source 
Signed-off-by: Ivan Kozlovic <ivan@synadia.com>
This commit is contained in:
Ivan Kozlovic
2018-08-29 16:48:08 -06:00
parent b79d618bf7
commit 0d3c1df932
1 changed files with 5 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
README.md
View File

@@ -565,7 +565,7 @@ authorization {
The NATS server supports authorization using subject-level permissions on a per-user basis. Permission-based authorization is available with [multi-user authentication](#authentication). See also the [Server Authorization](http://nats.io/documentation/server/gnatsd-authorization) documentation.
Before server `1.3.0`, it was only possible to define permissions allowing an authenticated user to pubslih or subscribe to certain subjects. Starting with `1.3.0`, it is now possible to also define permissions denying the right to publish or subscribe to specific subjects.
Before server `1.3.0`, it was only possible to define permissions allowing an authenticated user to publish or subscribe to certain subjects. Starting with `1.3.0`, it is now possible to also define permissions denying the right to publish or subscribe to specific subjects.
Each permission grant is an object with two fields: what subject(s) the authenticated user is allowed (or denied the right) to publish to, and what subject(s) the authenticated user is allowed (or denied the right) to subscribe to. The parser is generous at understanding what the intent is, so both arrays and singletons are processed. Subjects themselves can contain wildcards. Permissions make use of [variables](#variables).
@@ -635,8 +635,10 @@ Bob is a RESPONDER to any of Alice's requests, so Bob needs to be able to subscr
Important to note, 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 is not in the allow-list, or is in the deny-list, the action fails and is logged at the server, and an error message is returned to the client.
Most of the time it is fine to specify the subjects that an user is allowed to publish or subscribe to.
However, in some instances, it is much easier to configure the subjects that an user is not allowed to publish/subscribe .
Most of the time it is fine to specify the subjects that a user is allowed to publish or subscribe to.
However, in some instances, it is much easier to configure the subjects that a user is not allowed to publish/subscribe.
>Note that the `allow` clause is not required. If absent, it means that user is allowed to publish/subscribe to everything.
Here is an example showing how to use `allow` and `deny` clauses.
```