taigrr/nats.docs
1
0
Fork 0
mirror of https://github.com/taigrr/nats.docs synced 2025-01-18 04:03:23 -08:00
Code Issues Projects Releases Wiki Activity

Document allow-responses.

Browse Source
This commit is contained in:
aricart 2020-01-30 16:54:40 -04:00
parent cc952801a3
commit 5d18b8adfa
1 changed files with 33 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

33
nats-server/configuration/securing_nats/authorization.md
View File

@ -14,6 +14,8 @@ The `permissions` map specify subjects that can be subscribed to or published by
| :--- | :--- | | :--- | :--- |
| `publish` | subject, list of subjects, or permission map the client can publish | | `publish` | subject, list of subjects, or permission map the client can publish |
| `subscribe` | subject, list of subjects, or permission map the client can subscribe | | `subscribe` | subject, list of subjects, or permission map the client can subscribe |
| `allow_responses` | boolean or object |
## Permission Map ## Permission Map
@ -26,6 +28,22 @@ The `permission` map provides additional properties for configuring a `permissio
**Important Note** NATS Authorizations can be _allow lists_, _deny lists_, or both. It is important to not break request/reply patterns. In some cases \(as shown below\) 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 _allow listed_, the action fails and is logged at the server, and an error message is returned to the client. **Important Note** NATS Authorizations can be _allow lists_, _deny lists_, or both. It is important to not break request/reply patterns. In some cases \(as shown below\) 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 _allow listed_, the action fails and is logged at the server, and an error message is returned to the client.
## Allow Responses Map
The `allow_responses` option dynamically allows publishing to reply subjects, this works well for service responders.
When set to `true`, excepting any `publish` permissions, implicitly all publish permissions are denied unless it is the reply subject in a request received by the client.
The `allow_responses` map also allow you to configure a maximum number of responses and how long to allow the dynamic permission after a message is received.
| Property | Description |
| :--- | :--- |
| `max` | The maximum number of response messages that can be returned to a request. |
| `expires` | The duration of time to allow a response. Values such as `1s`, `1m`, `1h` (1 second, minute, hour) etc can be specified. |
If `allow_responses` set to `true` rather than a specific configuration, it defaults to the equivalent of `{ max: 1 }`.
**Important Note** When using `nsc` to configure your users, you can specify the `--allow-pub-response` and `--response-ttl` to control these settings.
## Example ## Example
Here is an example authorization configuration that uses _variables_ which defines four users, three of whom are assigned explicit permissions. Here is an example authorization configuration that uses _variables_ which defines four users, three of whom are assigned explicit permissions.
@ -95,3 +113,18 @@ authorization: {
} }
``` ```
Here's an example with `allow_responses`:
```text
authorization: {
users: [
{ user: a, password: a },
{ user: b, password: b, permissions: {subscribe: "q", allow_responses: true } },
{ user: c, password: c, permissions: {subscribe: "q", allow_responses: { max: 5, expires: "1m" } } }
]
}
```
User `a` has no restrictions. User `b` can listen on `q` for requests. If the received request has a reply subject it can reply at most one message. User `c` can also listen on `q` for requests, but is able to return at most 5 reply messages. The reply subject can be publish to for at most `1` minute.