[IMPROVED] Secure consumer create #3409
Conversation
| Durable string `json:"durable_name,omitempty"` | ||
| Name string `json:"name,omitempty"` |
There was a problem hiding this comment.
Instead of adding a new property to check, why not simply just say all consumers are durable. And that durables can be reaped by the server based on their inactive_threshold. Server can still autoname "ephemerals" when name is empty.
This would simplify the logic on clients, at the expense that durable_name would always be set, and name in ConsumerInfo would duplicate it.
There was a problem hiding this comment.
The only other concern then becomes how to reflect the new use of the API. If the consumer specifies a filter in the config, and the server matches the version with the new API, the client could simply use the new API. Otherwise, it can use the old API, allowing security compliance of the $JS.API.CONSUMER.CREATE... API without having to deal with model changes.
There was a problem hiding this comment.
Durables could not be reaped, so I prefer to not change that behavior and leave as is for existing clients.
Going forward all consumers will have a name and optional inactive threshold.
Note also that consumer info already had Name, so it now simply matches that for new style.
|
Let's make a call here. I decided to use the same subject prefix to ease issues with existing permissions and leafnodes etc. However that does mean we have to make sure that if you want a durable to either add a filter subject or fill in the durable name, since otherwise the server thinks its a legacy ephemeral create. I had the subject prefix different, and that is still and option for us, but I think I prefer using CONSUMER.CREATE. |
|
So this means that if you want to create a durable, the client specifies |
You can also create a named ephemeral by specifying name and inactive threshold. |
|
So feature wise we have still Durable and Ephemeral. Both will survive reboots Is it then that the only difference is essentially just positioning - a durable without a timeout is ephemeral? Then I guess implementation wise everything is a durable, the server only knows about durable consumers. If a client doesnt set You can additionally have R1 durables, memory only durables and so forth. But all are durables. Keeping the structures as is seem acceptible to me, no client changes needed to create an ephemeral or durable - the API simplification can use the features as it wish any old code continue to work? So if above is not correct, what is the technical need for adding/deprecating around names, what can not be implemented without deprecating durable name? These kind of API key changes, not on a major version boundary is really disruptive, so much so that I am thinking of just abandoning the terraform provider if the server simply cant keep stable interfaces since those systems require that. |
| @@ -48,7 +48,9 @@ type ConsumerInfo struct { | |||
| } | |||
|
|
|||
| type ConsumerConfig struct { | |||
| // Durable is deprecated. All consumers will have names. picked by clients. | |||
There was a problem hiding this comment.
We could soften if you like..
…s, and optional filter subject to the request subject. Similar to changes in direct get allows proper security if needed for filter subject selection. Signed-off-by: Derek Collison <[email protected]>
derekcollison
force-pushed
the
cc-secure
branch
from
8d0ca05
to
aa94a0b
Compare
| Durable string `json:"durable_name,omitempty"` | ||
| Name string `json:"name,omitempty"` |
There was a problem hiding this comment.
Why omitempty if All consumers will have names?
There was a problem hiding this comment.
It's good hygiene for older consumers and clients since it does not introduce this on the wire in those situations.
New consumer create that allows elevation of the stream and consumer names, and optional filter subject to the request subject.
Similar to changes in direct get allows proper security if needed for filter subject selection.
Signed-off-by: Derek Collison [email protected]
/cc @nats-io/core