Alberto Ricart aricart

Reissue

nsc has a reissue operator command that changes the operator's subject (main identity) with a new key and then traverses all known accounts (must be in the nsc data directory), and re-issues them with the new operator key.

If the --convert-to-signing-key option is used, the initial subject for the operator is added as a signing key. Ensuring that accounts in the wild (not found in the nsc data directory) will continue to work.

A small example showing delegated authentication (JWT) subject macros that reference values in the JWT. Note these macros are only valid in scoped signing keys (templates)

The macros are:

name() - the name field in the user JWT - note this shouldn't be used unless names are guaranteed to not have spaces.
subject() - the users public key (subject)
account-name() - the name field in the account account JWT - note this shouldn't be used unless names are guaranteed to not have spaces.
account-subject() the account public key
tag(name) - an user tag in the form name:value

JetStream Stream Sharing

This is an incremental tutorial on how to share JetStream assets between accounts. The options are not going to be fully explained unless they are vital. The tools used are nats cli and nsc, and both have excellent --help.

Note that this tutorial is expected to be followed in sequence.

Prerequisites

Understand imports and exports and JWT

mkdir test; cd test; npm init -y; npm install nats.ws@latest
nats-server -c server.conf &
deno run -A os.js

nats object ls
╭────────────────────────────────────────────────────────────────────────────────────╮
│                                Object Store Buckets                                │
├────────────────────────┬─────────────┬─────────────────────┬─────────┬─────────────┤
│ Bucket                 │ Description │ Created             │ Size    │ Last Update │

To run this example:

mkdir test
cd test
npm init -y
npm install nats.ws

# Copy `server.go`, `chat.html` and `chat.js` to the `test` directory

Hybrid Cluster

There are two server components, the cloud server and the internal or on-prem cluster.

On-Prem Server

The on-prem server, defines:

an account X with a single user x.
a leaf node configuration that maps a remote user leaf (and by extension leaf's account in the cloud) to account X

	So this example does a couple of things that are not in the obvious side.
	If none of the fields of the message are read, there's no work cost as the pipeline never runs

	If there's an error on the pipeline, it tosses, since the pipeline doesn't run until read, the error
	will pop when the user access the message. This is not great but cannot add an async condition,
	because the async portion is resolved when the message is read. Blowing up on access means that the
	trace will be on message access (not great, but not as bad as it can be)

	This means that if a pipeline is assigned far away, the error will be non-sensical and will lead
	to issues filed due to user code problems

	import {
	connect,
	credsAuthenticator,
	} from "https://raw.githubusercontent.com/nats-io/nats.deno/main/src/mod.ts";
	import { cli } from "https://deno.land/x/[email protected]/mod.ts";

	const root = cli({
	use:
	"ls [--server host:port] [--creds /path/to/creds] [--user n] [--pass pw] --name osname",
	short: "list objectstore assets",

	const { createUser, fromSeed } = require("nkeys.js");

	const te = new TextEncoder();
	const seed = "SAAGNKC24HXG5TD5XKKSWSVFRRKYQGZXF5LCTNXNNWCHO6C4WX3OTDQQNU";
	const a = fromSeed(te.encode(seed));
	const aid = a.getPublicKey();

	const u = createUser();
	const uid = u.getPublicKey();

	listen: "localhost:4222"
	cluster: {
	listen: "localhost:4333"
	}
	streaming: {
	store: "file"
	dir: "/tmp/stan-cluster/data"
	ft_group: "ft"
	}