SynadiaSynadia

Back to Newsletter

NATS Weekly #28

Byron Ruth

Published on May 30th, 2022

Week of May 23 - 29, 2022

🗞 Announcements, writings, and projects

A short list of  announcements, blog posts, projects updates and other news.

⚡Releases

Official releases from NATS repos and others in the ecosystem.

⚙️ Projects️

Open Source and commercial projects (or products) that use or extends NATS.

📖 Articles

Blog posts, tutorials, or any other text-based content about NATS.

💬 Discussions

Github Discussions from various NATS repositories.

💡 Recently asked questions

Questions sourced from Slack, Twitter, or individuals. Responses and examples are in my own words, unless otherwise noted.

What does the new RePublish feature do?

In NATS server v2.8.3, a new curious feature landed. Here is the first PR that introduced it with the commit message:

**Enable republishing of messages once stored in a stream. **This enables lightweight distribution of messages to very large number of NATS subscribers. We add in metadata as headers that allows for gap detection which enables initial value (via JetStream, maybe KV) and real-time NATS core sub updates but all being globally ordered and gap detection allowed, even for a subset of messages.

v1.16.0 of the Go client was released around the same time which added the first (experimental) client support for this.

So what does it do? Given a stream bound to a a subject space, e.g. foo.>, a the RePublish config is a subject mapping from a source subject to a destination. The source subject can be a subset of the stream subject space (i.e. the entirety of it.. or a more granular subset). The destination can be any subject that does not overlap with the source subject (otherwise we would be in an infinite loop) and has sufficient wildcards to embed the source wildcards. 🤔

For example, a source of foo.> can be republished to bar.> . Likewise foo.* to bar.*, but foo.> to bar.* would not be valid since the source may have more than one token (there may be other semantics introduced during its experimental phase).

What is the use case? As noted in the commit message, it likely geared towards use cases having a single stream of truth, but that needs to be broadcasted out to many, many clients.. such as a fleet of devices. The only current alternative is that each client creates a consumer + subscription (it can be emphemeral to be lighter weight), but this is still vastly more expensive than a republish to a core NATS subject.

How can you explicitly revoke a user if permissions become more restrictive?

Thanks to Todd Beets for help on addressing my situation and concern with this!

While developing an application, I ran into a situation where a user was created using the the decentralized JWT method with certain permissions.. and then later, the permission were deemed too permissive. However, the person/team responsible for getting a new set of user credentials to update and deploy their client was not available. In this particular instance, there was a security concern.

As noted in the linked docs above, user JWTs are not synced with the server, so updating a user's permissions locally without distribution and deployment to the application using it won't solve the problem.

What can be done?

Use the nsc revocations add-user command which explicit revokes a user and stores this server-side. Once a revocation is pushed to the server, it determine clients connected with this user and disconnect them.

Note that this is a last resort and will disconnect all clients using this user regardless of which version of a JWT is being used (even if a permissive/valid one). However, once all the clients are confirmed to be updated with the JWT containing the new permissions, the user can be unrevoked using nsc revocations delete-user.

Back to Newsletter