@axonflow/sdk 9.1.0 → 9.3.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (76) hide show
  1. package/README.md +238 -22
  2. package/dist/cjs/adapters/langgraph.d.ts.map +1 -1
  3. package/dist/cjs/adapters/langgraph.js +20 -0
  4. package/dist/cjs/adapters/langgraph.js.map +1 -1
  5. package/dist/cjs/authzen.d.ts +353 -0
  6. package/dist/cjs/authzen.d.ts.map +1 -0
  7. package/dist/cjs/authzen.js +901 -0
  8. package/dist/cjs/authzen.js.map +1 -0
  9. package/dist/cjs/client.d.ts +135 -9
  10. package/dist/cjs/client.d.ts.map +1 -1
  11. package/dist/cjs/client.js +397 -30
  12. package/dist/cjs/client.js.map +1 -1
  13. package/dist/cjs/heartbeat.d.ts +55 -4
  14. package/dist/cjs/heartbeat.d.ts.map +1 -1
  15. package/dist/cjs/heartbeat.js +86 -7
  16. package/dist/cjs/heartbeat.js.map +1 -1
  17. package/dist/cjs/index.d.ts +6 -0
  18. package/dist/cjs/index.d.ts.map +1 -1
  19. package/dist/cjs/index.js +55 -1
  20. package/dist/cjs/index.js.map +1 -1
  21. package/dist/cjs/read-identity.d.ts +267 -0
  22. package/dist/cjs/read-identity.d.ts.map +1 -0
  23. package/dist/cjs/read-identity.js +329 -0
  24. package/dist/cjs/read-identity.js.map +1 -0
  25. package/dist/cjs/telemetry.d.ts +176 -13
  26. package/dist/cjs/telemetry.d.ts.map +1 -1
  27. package/dist/cjs/telemetry.js +403 -37
  28. package/dist/cjs/telemetry.js.map +1 -1
  29. package/dist/cjs/types/authzen.gen.d.ts +407 -0
  30. package/dist/cjs/types/authzen.gen.d.ts.map +1 -0
  31. package/dist/cjs/types/authzen.gen.js +804 -0
  32. package/dist/cjs/types/authzen.gen.js.map +1 -0
  33. package/dist/cjs/types/config.d.ts +43 -1
  34. package/dist/cjs/types/config.d.ts.map +1 -1
  35. package/dist/cjs/types/hitl.js +1 -1
  36. package/dist/cjs/types/hitl.js.map +1 -1
  37. package/dist/cjs/version.d.ts +1 -1
  38. package/dist/cjs/version.js +1 -1
  39. package/dist/esm/adapters/langgraph.d.ts.map +1 -1
  40. package/dist/esm/adapters/langgraph.js +20 -0
  41. package/dist/esm/adapters/langgraph.js.map +1 -1
  42. package/dist/esm/authzen.d.ts +353 -0
  43. package/dist/esm/authzen.d.ts.map +1 -0
  44. package/dist/esm/authzen.js +886 -0
  45. package/dist/esm/authzen.js.map +1 -0
  46. package/dist/esm/client.d.ts +135 -9
  47. package/dist/esm/client.d.ts.map +1 -1
  48. package/dist/esm/client.js +397 -30
  49. package/dist/esm/client.js.map +1 -1
  50. package/dist/esm/heartbeat.d.ts +55 -4
  51. package/dist/esm/heartbeat.d.ts.map +1 -1
  52. package/dist/esm/heartbeat.js +85 -7
  53. package/dist/esm/heartbeat.js.map +1 -1
  54. package/dist/esm/index.d.ts +6 -0
  55. package/dist/esm/index.d.ts.map +1 -1
  56. package/dist/esm/index.js +17 -0
  57. package/dist/esm/index.js.map +1 -1
  58. package/dist/esm/read-identity.d.ts +267 -0
  59. package/dist/esm/read-identity.d.ts.map +1 -0
  60. package/dist/esm/read-identity.js +320 -0
  61. package/dist/esm/read-identity.js.map +1 -0
  62. package/dist/esm/telemetry.d.ts +176 -13
  63. package/dist/esm/telemetry.d.ts.map +1 -1
  64. package/dist/esm/telemetry.js +397 -37
  65. package/dist/esm/telemetry.js.map +1 -1
  66. package/dist/esm/types/authzen.gen.d.ts +407 -0
  67. package/dist/esm/types/authzen.gen.d.ts.map +1 -0
  68. package/dist/esm/types/authzen.gen.js +779 -0
  69. package/dist/esm/types/authzen.gen.js.map +1 -0
  70. package/dist/esm/types/config.d.ts +43 -1
  71. package/dist/esm/types/config.d.ts.map +1 -1
  72. package/dist/esm/types/hitl.js +1 -1
  73. package/dist/esm/types/hitl.js.map +1 -1
  74. package/dist/esm/version.d.ts +1 -1
  75. package/dist/esm/version.js +1 -1
  76. package/package.json +1 -1
@@ -0,0 +1,901 @@
1
+ "use strict";
2
+ /**
3
+ * AuthZEN-native authorization for the AxonFlow SDK.
4
+ *
5
+ * This is the surface the ADR-065 compatibility plan commits to in all five
6
+ * SDKs. It talks to `POST /api/v1/access/evaluation`, whose wire shape is
7
+ * generated from the platform's canonical contract (see
8
+ * `src/types/authzen.gen.ts`); nothing in this file re-states a field name or
9
+ * an enum value.
10
+ *
11
+ * ## What this replaces, and when
12
+ *
13
+ * Nothing yet. The existing decision surface (`decide`, `explainDecision` and
14
+ * the gateway/proxy methods) stays wire-stable through all of v11 and is not
15
+ * deprecated here. This is the surface to write NEW integrations against,
16
+ * because at v11 the engine behind it becomes the ADR-065 Policy Decision Point
17
+ * with no wire change — an integration written against it migrates once rather
18
+ * than twice. See `docs/AUTHZEN_MIGRATION_DRAFT.md`.
19
+ *
20
+ * ## The one thing worth knowing before you call it
21
+ *
22
+ * The server refuses anything it cannot evaluate rather than evaluating around
23
+ * it. Send a subject property, an unrecognised context member, or an argument
24
+ * beside the query, and you get an `AuthZENRefusal` naming the exact member —
25
+ * not a decision computed without it. That is deliberate: a decision that
26
+ * silently ignored an attribute would tell you the attribute was weighed when
27
+ * it was not, and every audit of that decision would inherit the claim.
28
+ *
29
+ * So treat an `AuthZENRefusal` as "fix the request", and retry only when
30
+ * `refusal.retryable` is true.
31
+ */
32
+ var _a;
33
+ Object.defineProperty(exports, "__esModule", { value: true });
34
+ exports.AuthZENDecision = exports.AuthZENAttribute = exports.AuthZENProtocolError = exports.AuthZENRefusal = exports.AUTHZEN_UNKNOWN_REQUIRED_ABSENT = exports.AUTHZEN_UNKNOWN_MALFORMED_VALUE = exports.AUTHZEN_UNKNOWN_CLOSURE_TRUNCATED = exports.AUTHZEN_UNKNOWN_CLOSURE_UNAVAILABLE = exports.AUTHZEN_UNKNOWN_SCHEMA_MISMATCH = exports.AUTHZEN_UNKNOWN_STALE = exports.AUTHZEN_UNKNOWN_RESOLUTION_FAILED = exports.AUTHZEN_UNKNOWN_NOT_SUPPLIED = exports.AUTHZEN_PROFILE_HEADER = exports.AUTHZEN_PATH = exports.AUTHZEN_ATTRIBUTE_MARKER = void 0;
35
+ exports.resolveEnvelope = resolveEnvelope;
36
+ exports.checkEnvelopeComplete = checkEnvelopeComplete;
37
+ exports.buildEnvelope = buildEnvelope;
38
+ exports.evaluateEnvelope = evaluateEnvelope;
39
+ exports.assertFullyResolved = assertFullyResolved;
40
+ exports.toWire = toWire;
41
+ const errors_1 = require("./errors");
42
+ const authzen_gen_1 = require("./types/authzen.gen");
43
+ /**
44
+ * The marker every tri-state attribute carries. See {@link AuthZENAttribute}.
45
+ *
46
+ * Exported so a caller building attributes across a serialisation boundary can
47
+ * reconstruct one the SDK will still recognise.
48
+ */
49
+ exports.AUTHZEN_ATTRIBUTE_MARKER = '__axonflow_authzen_attribute__';
50
+ /**
51
+ * AUTHZEN_PATH and AUTHZEN_PROFILE_HEADER are GENERATED (./types/authzen.gen) and
52
+ * re-exported here under the names this module has always had. They used to be
53
+ * literals in this file - the SDK's own copy of two strings the platform also
54
+ * wrote by hand - and nothing compared the copies (axonflow-enterprise#3603).
55
+ * The artifact now carries them, so a platform rename is a regenerate-and-diff
56
+ * failure rather than a runtime 404.
57
+ *
58
+ * The SDK always sends the profile header. AuthZEN 1.0's response is a bare
59
+ * boolean, and the four-valued state, the obligations and the approval challenge
60
+ * ride in the response context, which the server returns only to a caller that
61
+ * asked for it by version. This SDK understands the profile, so there is no
62
+ * reason to ask for less than it can read - and a response WITHOUT the context is
63
+ * therefore a protocol failure here rather than a decision with no obligations.
64
+ */
65
+ var authzen_gen_2 = require("./types/authzen.gen");
66
+ Object.defineProperty(exports, "AUTHZEN_PATH", { enumerable: true, get: function () { return authzen_gen_2.AUTHZEN_PATH; } });
67
+ Object.defineProperty(exports, "AUTHZEN_PROFILE_HEADER", { enumerable: true, get: function () { return authzen_gen_2.AUTHZEN_PROFILE_HEADER; } });
68
+ const authzen_gen_3 = require("./types/authzen.gen");
69
+ // ---------------------------------------------------------------------------
70
+ // Why an attribute could not be established.
71
+ // ---------------------------------------------------------------------------
72
+ //
73
+ // These mirror ADR-065's tri-state reason codes so an operator reading an SDK
74
+ // refusal and an operator reading a platform trace use the same words. They are
75
+ // CLIENT-LOCAL: an unknown attribute never reaches the wire, because the whole
76
+ // point is that the request is not sent. The reason is a free-form string on
77
+ // purpose — a closed set hand-copied from the platform would be a transcription
78
+ // that drifts, and it would buy nothing, since nothing on the far side reads it.
79
+ exports.AUTHZEN_UNKNOWN_NOT_SUPPLIED = 'attribute_not_supplied';
80
+ exports.AUTHZEN_UNKNOWN_RESOLUTION_FAILED = 'resolution_failed';
81
+ exports.AUTHZEN_UNKNOWN_STALE = 'stale';
82
+ exports.AUTHZEN_UNKNOWN_SCHEMA_MISMATCH = 'schema_mismatch';
83
+ exports.AUTHZEN_UNKNOWN_CLOSURE_UNAVAILABLE = 'closure_unavailable';
84
+ exports.AUTHZEN_UNKNOWN_CLOSURE_TRUNCATED = 'closure_truncated';
85
+ exports.AUTHZEN_UNKNOWN_MALFORMED_VALUE = 'malformed_value';
86
+ exports.AUTHZEN_UNKNOWN_REQUIRED_ABSENT = 'required_attribute_absent';
87
+ /**
88
+ * The request was NOT evaluated, and here is the typed reason why.
89
+ *
90
+ * A refusal is not a denial. `decision: false` says the request WAS evaluated
91
+ * and the answer was no; a refusal says no decision exists. Code that treats
92
+ * every error as a deny fails closed — which is safe — but will block traffic
93
+ * that should have been allowed once the request is corrected.
94
+ *
95
+ * `refusedBy` says who made the call. `'gateway'` is a refusal document the
96
+ * server sent; `'client'` is this SDK declining to send a request it can
97
+ * already see will not be evaluated — an attribute the caller could not
98
+ * resolve, or an evaluation with no subject. The code vocabulary is shared
99
+ * because the REASONS are shared: an incomplete evaluation is an incomplete
100
+ * evaluation whoever notices it first.
101
+ */
102
+ class AuthZENRefusal extends errors_1.AxonFlowError {
103
+ constructor(code, message, options) {
104
+ super(message, {
105
+ code,
106
+ pointer: options.pointer,
107
+ supported: options.supported,
108
+ requestId: options.requestId,
109
+ refusedBy: options.refusedBy,
110
+ });
111
+ this.name = 'AuthZENRefusal';
112
+ this.code = code;
113
+ this.pointer = options.pointer;
114
+ this.supported = options.supported;
115
+ this.requestId = options.requestId;
116
+ this.refusedBy = options.refusedBy;
117
+ Object.setPrototypeOf(this, AuthZENRefusal.prototype);
118
+ }
119
+ /** Build a refusal from the structured document the server sent. */
120
+ static fromBody(body) {
121
+ return new AuthZENRefusal(body.code, body.message, {
122
+ refusedBy: 'gateway',
123
+ pointer: body.pointer,
124
+ supported: body.supported,
125
+ requestId: body.request_id,
126
+ });
127
+ }
128
+ /**
129
+ * Whether sending the same request again could give a different answer.
130
+ *
131
+ * Only a dependency failure the GATEWAY reported is. Every other code names
132
+ * something about the request itself, which will not change on a retry — so
133
+ * a client that retries on any refusal burns its budget on requests that
134
+ * cannot succeed.
135
+ *
136
+ * A client-side refusal is never retryable, whatever its code: this SDK does
137
+ * not resolve the caller's attributes, so nothing it can do will change the
138
+ * answer. Reading retryability off the code alone would have told a caller to
139
+ * retry an attribute its own resolver failed to produce.
140
+ */
141
+ get retryable() {
142
+ return this.refusedBy === 'gateway' && this.code === authzen_gen_1.AUTHZEN_ERROR_CODE_EVALUATION_UNAVAILABLE;
143
+ }
144
+ }
145
+ exports.AuthZENRefusal = AuthZENRefusal;
146
+ /**
147
+ * A 200 whose body this build cannot safely interpret.
148
+ *
149
+ * Deliberately NOT an `AuthZENRefusal`. A refusal carries the server's own
150
+ * typed code from a closed vocabulary the server owns; a response this build
151
+ * cannot read is not something the server said, and dressing it in a server
152
+ * code would tell the caller the gateway refused when it did not. The two also
153
+ * demand different actions: a refusal means fix the request, a protocol error
154
+ * means upgrade the SDK or go and look at the deployment.
155
+ *
156
+ * It is always fail-closed: no decision is returned, so a caller that lets it
157
+ * propagate blocks the operation.
158
+ */
159
+ class AuthZENProtocolError extends errors_1.AxonFlowError {
160
+ constructor(message) {
161
+ super(message);
162
+ this.name = 'AuthZENProtocolError';
163
+ Object.setPrototypeOf(this, AuthZENProtocolError.prototype);
164
+ }
165
+ }
166
+ exports.AuthZENProtocolError = AuthZENProtocolError;
167
+ /**
168
+ * One policy-visible attribute in exactly one of three states.
169
+ *
170
+ * `undefined` and `null` cannot express this. ADR-065's model has three:
171
+ *
172
+ * - `known` — the authoritative source returned a value. It is sent.
173
+ * - `absent` — the source successfully established that there is NO value.
174
+ * Absence is a FACT, not a failure, so the member is omitted and the request
175
+ * is sent: a policy that handles absence gets to handle it.
176
+ * - `unknown` — the value could not be established. The request is NOT sent.
177
+ * Sending it would have the gateway evaluate as though the attribute were
178
+ * absent, and the resulting decision — and every audit of it — would record
179
+ * that an attribute was weighed when nobody ever read it. That is the exact
180
+ * failure the whole surface refuses to commit, one hop earlier.
181
+ *
182
+ * Collapsing absent into unknown is the defect this type exists to prevent, and
183
+ * it is not hypothetical: on the platform side an ABSENT `subject.type` was
184
+ * read as the one supported value, so omitting the field bypassed the
185
+ * impersonation refusal that naming it correctly triggered.
186
+ *
187
+ * Where it may be used: inside the ATTRIBUTE bags — `context` on a request or a
188
+ * bulk envelope, and the `properties` bag on a subject, action or resource — at
189
+ * any depth. Not on the structural members (`subject.id`, `action.name`,
190
+ * `resource.type` …): those are the identity of the question being asked, not
191
+ * data about it, and an identity the caller cannot resolve is not an attribute
192
+ * whose absence a policy could evaluate — there is simply no request to make.
193
+ *
194
+ * @example
195
+ * ```typescript
196
+ * AuthZENAttribute.known('acme-corp');
197
+ * AuthZENAttribute.absent();
198
+ * AuthZENAttribute.unknown(AUTHZEN_UNKNOWN_RESOLUTION_FAILED);
199
+ * ```
200
+ */
201
+ class AuthZENAttribute {
202
+ constructor(state, value, reason) {
203
+ /**
204
+ * The marker, carried as an ordinary ENUMERABLE property.
205
+ *
206
+ * Recognising an attribute by `instanceof` alone has a silent failure in the
207
+ * dangerous direction: a bundler that duplicated this package gives two
208
+ * distinct classes. A non-enumerable Symbol brand fixes that and introduces
209
+ * the same failure by another route - every ordinary copy strips it, so
210
+ * `structuredClone`, a spread, a JSON round trip or a worker boundary turned
211
+ * an UNKNOWN attribute back into ordinary data and SENT it. Measured against
212
+ * a live gateway.
213
+ *
214
+ * Recognising it by SHAPE alone has the mirror failure: a caller's own bag
215
+ * carrying `state`/`value`/`reason` is read as an attribute, and a legitimate
216
+ * request is refused with a message asserting the caller could not establish
217
+ * a value it did establish.
218
+ *
219
+ * An enumerable marker closes both. It survives every ordinary copy, and no
220
+ * caller's data carries it by accident. The Python sibling uses the same key
221
+ * for the same reason.
222
+ */
223
+ this[_a] = true;
224
+ this.state = state;
225
+ this.value = value;
226
+ this.reason = reason;
227
+ }
228
+ /** The source returned this value. */
229
+ static known(value) {
230
+ return new AuthZENAttribute('known', value, '');
231
+ }
232
+ /** The source established that there is no value. */
233
+ static absent() {
234
+ return new AuthZENAttribute('absent', undefined, '');
235
+ }
236
+ /**
237
+ * The value could not be established, for the named reason.
238
+ *
239
+ * The reason is mandatory. An unknown with no reason carries no more than
240
+ * `undefined` already did, and the whole point of the third state is that it
241
+ * says why.
242
+ */
243
+ static unknown(reason) {
244
+ if (!reason || reason.trim() === '') {
245
+ throw new errors_1.AxonFlowError('an unknown attribute must name why it could not be established; an unknown with ' +
246
+ 'no reason carries no more information than undefined, which is the collapse ' +
247
+ 'this type exists to prevent');
248
+ }
249
+ return new AuthZENAttribute('unknown', undefined, reason);
250
+ }
251
+ /**
252
+ * Whether `value` is a tri-state attribute, however it was copied.
253
+ *
254
+ * See the marker above for why this is neither a bare `instanceof` nor a
255
+ * structural shape check.
256
+ *
257
+ * Recognition keys on the MARKER alone, deliberately, and not on the marker
258
+ * plus a state this build happens to know.
259
+ *
260
+ * Pairing them was a fail-open (#263). A document carrying
261
+ * `__axonflow_authzen_attribute__: true` with any other `state` — a newer
262
+ * producer's, or a corrupted one — was reported as NOT an attribute, and so
263
+ * was walked as ordinary data and sent on the wire, marker key and all. By
264
+ * the surface's own reasoning that document IS an attribute; it is one this
265
+ * build cannot interpret. Evaluating around it records an attribute nobody
266
+ * resolved as one that was weighed, and it leaks the marker convention to the
267
+ * gateway.
268
+ *
269
+ * Recognising it here routes it to the same refusal an `unknown` attribute
270
+ * gets: the resolver matches `known` and `absent` explicitly and refuses
271
+ * everything else, so an unrecognised state (including a missing one) refuses
272
+ * locally, non-retryably, with a pointer to the member — which is what the Go
273
+ * SDK does (sdk-go#210).
274
+ *
275
+ * A marker that is present but not boolean `true` stays data: only a positive
276
+ * self-identification counts, so a caller's own bag with a similarly-named key
277
+ * cannot be turned into a refusal.
278
+ */
279
+ static is(value) {
280
+ if (value instanceof AuthZENAttribute)
281
+ return true;
282
+ if (typeof value !== 'object' || value === null)
283
+ return false;
284
+ const candidate = value;
285
+ return candidate[exports.AUTHZEN_ATTRIBUTE_MARKER] === true;
286
+ }
287
+ }
288
+ exports.AuthZENAttribute = AuthZENAttribute;
289
+ _a = exports.AUTHZEN_ATTRIBUTE_MARKER;
290
+ /**
291
+ * The decision, with the readings a Policy Enforcement Point acts on.
292
+ *
293
+ * It implements the generated wire type rather than replacing it, so `decision`
294
+ * and `context` remain exactly what the server sent while the readings below
295
+ * stay in hand-written code the generator never has to know about.
296
+ */
297
+ class AuthZENDecision {
298
+ constructor(response) {
299
+ this.decision = response.decision;
300
+ this.context = response.context;
301
+ }
302
+ /**
303
+ * Whether the enforcement point may proceed.
304
+ *
305
+ * Read this rather than `decision`. `decision` is AuthZEN 1.0's collapsed
306
+ * boolean; the operational STATE is what the policy engine actually produced,
307
+ * and exactly one state permits execution. Requiring both means a response
308
+ * whose boolean and state disagree can never be read as an allow — and such a
309
+ * response is refused before it gets here anyway, so this is the second of
310
+ * two locks rather than the only one.
311
+ *
312
+ * An allow with an undischarged MANDATORY obligation is not an allow. See
313
+ * `mandatoryObligations`.
314
+ */
315
+ get allowed() {
316
+ return (this.decision === true &&
317
+ this.context !== undefined &&
318
+ this.context.state === authzen_gen_1.AUTHZEN_OPERATIONAL_STATE_ALLOW);
319
+ }
320
+ /**
321
+ * The four-valued operational state.
322
+ *
323
+ * `ERROR` when there is no context. Unreachable via `evaluate`, which refuses
324
+ * a context-less 200 before constructing this — but the type is public and a
325
+ * caller can build one by hand, and the safe reading of an outcome that
326
+ * carries no state is not ALLOW.
327
+ */
328
+ get state() {
329
+ return this.context ? this.context.state : authzen_gen_1.AUTHZEN_OPERATIONAL_STATE_ERROR;
330
+ }
331
+ /**
332
+ * The id of the evaluation that DETERMINED this outcome.
333
+ *
334
+ * For a bulk envelope this is the entry that decided the meet, not the last
335
+ * one evaluated: it is the id an operator looks up to explain the answer.
336
+ */
337
+ get decisionId() {
338
+ return this.context?.decision_id;
339
+ }
340
+ /** The safe machine-readable reason code, when the server sent one. */
341
+ get reason() {
342
+ return this.context?.reason;
343
+ }
344
+ /** The coarse outcome category, when the server sent one. */
345
+ get category() {
346
+ return this.context?.category;
347
+ }
348
+ /** Instructions the enforcement point must discharge before proceeding. */
349
+ get obligations() {
350
+ return this.context?.obligations ?? [];
351
+ }
352
+ /**
353
+ * The obligations that are not optional.
354
+ *
355
+ * A mandatory obligation that cannot be discharged means the operation must
356
+ * NOT proceed, even though `allowed` is true. This SDK cannot make that call
357
+ * for you — whether your enforcement point can discharge a redaction is a
358
+ * fact about your seam, not about the decision — so it gives you the list and
359
+ * stays out of the way.
360
+ */
361
+ get mandatoryObligations() {
362
+ return this.obligations.filter(obligation => obligation.mandatory);
363
+ }
364
+ /** The approval challenge, when the state is CHALLENGE. */
365
+ get approval() {
366
+ return this.context?.approval;
367
+ }
368
+ }
369
+ exports.AuthZENDecision = AuthZENDecision;
370
+ // ---------------------------------------------------------------------------
371
+ // Tri-state resolution
372
+ // ---------------------------------------------------------------------------
373
+ // RFC 6901. A correlation key containing a slash would otherwise produce a
374
+ // pointer naming a member that does not exist, on the refusal whose entire
375
+ // diagnostic value is the pointer.
376
+ function escapePointerToken(token) {
377
+ return token.replace(/~/g, '~0').replace(/\//g, '~1');
378
+ }
379
+ class Unresolvable extends Error {
380
+ constructor(pointer, reason) {
381
+ super(pointer);
382
+ this.pointer = pointer;
383
+ this.reason = reason;
384
+ }
385
+ }
386
+ // Distinguishes "this member resolved to no value, drop it" from "this member
387
+ // resolved to the value null". They are different: a caller may legitimately
388
+ // send a JSON null, and reusing null for the drop signal would silently rewrite
389
+ // one into the other.
390
+ const DROP = Symbol('authzen.absent');
391
+ /**
392
+ * How deep an attribute bag may nest before the SDK stops walking it.
393
+ *
394
+ * Without a bound, a bag that refers to itself recurses until the engine gives
395
+ * up, and the caller gets a `RangeError` out of `evaluate` - an error type
396
+ * nothing documents and no enforcement point catches. A bound turns that into
397
+ * the same typed refusal every other malformed bag gets. 64 is far past
398
+ * anything a policy attribute path plausibly nests and far short of the stack.
399
+ */
400
+ const MAX_ATTRIBUTE_DEPTH = 64;
401
+ function resolveValue(value, pointer, depth = 0) {
402
+ if (depth > MAX_ATTRIBUTE_DEPTH) {
403
+ throw new Unresolvable(pointer, `nests deeper than ${MAX_ATTRIBUTE_DEPTH} levels, which this SDK will not walk; a bag ` +
404
+ `that refers to itself would otherwise recurse until the engine stopped`);
405
+ }
406
+ if (AuthZENAttribute.is(value)) {
407
+ if (value.state === 'known') {
408
+ // A known attribute may itself hold a container carrying more
409
+ // attributes; resolving the payload keeps the rule uniform rather than
410
+ // depending on how deeply a caller nested its resolver output.
411
+ return resolveValue(value.value, pointer, depth + 1);
412
+ }
413
+ if (value.state === 'absent')
414
+ return DROP;
415
+ throw new Unresolvable(pointer, value.reason);
416
+ }
417
+ if (Array.isArray(value)) {
418
+ // An ABSENT element is dropped from the list rather than left as a hole. A
419
+ // list with a gap in it is a different list, and the index a policy reads
420
+ // would shift under it either way; dropping is the reading that matches
421
+ // "there is no value here".
422
+ const items = [];
423
+ value.forEach((item, index) => {
424
+ const resolved = resolveValue(item, `${pointer}/${index}`, depth + 1);
425
+ if (resolved !== DROP)
426
+ items.push(resolved);
427
+ });
428
+ return items;
429
+ }
430
+ if (typeof value === 'object' && value !== null) {
431
+ const out = {};
432
+ Object.keys(value).forEach(key => {
433
+ const resolved = resolveValue(value[key], `${pointer}/${escapePointerToken(key)}`, depth + 1);
434
+ if (resolved === DROP)
435
+ return;
436
+ // defineProperty, not `out[key] = …`. A plain assignment to the key
437
+ // `__proto__` invokes the inherited setter instead of creating a member,
438
+ // so a context carrying `__proto__` - which `JSON.parse` produces as an
439
+ // ordinary own property - VANISHED from the request with no refusal.
440
+ // That is "mapped or refused, never silently ignored" broken by this SDK,
441
+ // in the one place the gateway cannot see it: the server refuses the
442
+ // member by name, and it never arrived. It reaches the wire now.
443
+ Object.defineProperty(out, key, {
444
+ value: resolved,
445
+ writable: true,
446
+ enumerable: true,
447
+ configurable: true,
448
+ });
449
+ });
450
+ return out;
451
+ }
452
+ return value;
453
+ }
454
+ /**
455
+ * Resolve one attribute bag.
456
+ *
457
+ * ABSENCE DOES NOT CASCADE. A bag whose every member resolved absent is sent as
458
+ * an empty object, not deleted: the bag is the caller's structure and the
459
+ * attributes are the data inside it, and an SDK that removed a container the
460
+ * caller placed would be editing the question rather than resolving the answer.
461
+ *
462
+ * The lever a caller wants sits one level in, which is where the attributes
463
+ * are: `{ args, correlation: AuthZENAttribute.absent() }` drops `correlation`
464
+ * and keeps everything else. Omitting the bag itself is ordinary TypeScript —
465
+ * do not pass it — because a bag that is not part of the question is not an
466
+ * attribute whose absence anything could evaluate.
467
+ */
468
+ function resolveBag(bag, pointer) {
469
+ if (bag === undefined)
470
+ return undefined;
471
+ return resolveValue(bag, pointer);
472
+ }
473
+ // Every member the caller wrote is CARRIED FORWARD, and only the attribute bags
474
+ // are rewritten.
475
+ //
476
+ // These functions used to whitelist-copy `{type, id, properties}`, which meant a
477
+ // member the contract does not declare - `{"type":"gateway","id":"g1",
478
+ // "department":"finance"}` - was deleted here, before the generated validator
479
+ // ran, and the request went out without it and without a refusal. The
480
+ // validator's own documentation says it "catches a member the caller invented
481
+ // before it becomes a 422"; the whitelist made that claim false for exactly
482
+ // those members. Python refuses them at model construction, so this was also a
483
+ // place the two SDKs answered the same request differently.
484
+ //
485
+ // Spreading means an invented member survives to `validateAuthZENEnvelope` and
486
+ // is refused by name, with its pointer.
487
+ function resolveSubject(subject, at) {
488
+ if (!subject)
489
+ return undefined;
490
+ return { ...subject, properties: resolveBag(subject.properties, `${at}/subject/properties`) };
491
+ }
492
+ function resolveAction(action, at) {
493
+ if (!action)
494
+ return undefined;
495
+ return { ...action, properties: resolveBag(action.properties, `${at}/action/properties`) };
496
+ }
497
+ function resolveResource(resource, at) {
498
+ if (!resource)
499
+ return undefined;
500
+ return { ...resource, properties: resolveBag(resource.properties, `${at}/resource/properties`) };
501
+ }
502
+ function resolveRequest(request, at) {
503
+ return {
504
+ ...request,
505
+ subject: resolveSubject(request.subject, at),
506
+ action: resolveAction(request.action, at),
507
+ resource: resolveResource(request.resource, at),
508
+ context: resolveBag(request.context, `${at}/context`),
509
+ };
510
+ }
511
+ /**
512
+ * Return the envelope with every tri-state attribute resolved to the wire.
513
+ *
514
+ * Throws `AuthZENRefusal` with `refusedBy: 'client'` and the JSON Pointer of
515
+ * the offending member when an attribute is UNKNOWN.
516
+ *
517
+ * The pointers match the server's own vocabulary — `/evaluation/...` for a
518
+ * singular envelope, `/evaluations/evaluations/<i>/...` for a plural entry — so
519
+ * a client-side refusal and a gateway refusal name the same member the same
520
+ * way, and a caller does not have to learn two pointer dialects.
521
+ */
522
+ function resolveEnvelope(envelope) {
523
+ try {
524
+ // BOTH members are resolved when both are present, rather than the first
525
+ // one winning. Python's models refuse a two-member envelope at
526
+ // construction; TypeScript has no such moment, so an early return here
527
+ // would silently DROP the second member and send a request the caller did
528
+ // not write — and the exactly-one-of rule, which lives in the generated
529
+ // validator, would never see the violation it exists to refuse. One
530
+ // implementation of that rule, not two.
531
+ const out = {};
532
+ if (envelope.evaluation !== undefined && envelope.evaluation !== null) {
533
+ out.evaluation = resolveRequest(envelope.evaluation, '/evaluation');
534
+ }
535
+ if (envelope.evaluations !== undefined && envelope.evaluations !== null) {
536
+ const bulk = envelope.evaluations;
537
+ out.evaluations = {
538
+ subject: resolveSubject(bulk.subject, '/evaluations'),
539
+ action: resolveAction(bulk.action, '/evaluations'),
540
+ resource: resolveResource(bulk.resource, '/evaluations'),
541
+ context: resolveBag(bulk.context, '/evaluations/context'),
542
+ evaluations: (bulk.evaluations ?? []).map((entry, index) => resolveRequest(entry, `/evaluations/evaluations/${index}`)),
543
+ };
544
+ }
545
+ if (out.evaluation !== undefined || out.evaluations !== undefined) {
546
+ return out;
547
+ }
548
+ }
549
+ catch (err) {
550
+ if (!(err instanceof Unresolvable))
551
+ throw err;
552
+ throw new AuthZENRefusal(authzen_gen_1.AUTHZEN_ERROR_CODE_UNEVALUABLE_ATTRIBUTE, `the attribute at ${err.pointer} could not be established (${err.reason}), so this ` +
553
+ `request was not sent. The gateway would have evaluated as though the attribute ` +
554
+ `had no value, and the decision — and every audit of it — would record that it ` +
555
+ `was considered when nothing read it. Establish the value, or send it as an ` +
556
+ `explicitly ABSENT attribute if the source proved there is none.`, { refusedBy: 'client', pointer: err.pointer });
557
+ }
558
+ throw new AuthZENRefusal(authzen_gen_1.AUTHZEN_ERROR_CODE_MALFORMED_ENVELOPE, 'the envelope names neither an evaluation nor an evaluations member', { refusedBy: 'client', pointer: '' });
559
+ }
560
+ // ---------------------------------------------------------------------------
561
+ // Completeness
562
+ // ---------------------------------------------------------------------------
563
+ /**
564
+ * Check the one invariant the artifact says it cannot express.
565
+ *
566
+ * The artifact marks every member of `authzen_request` structurally optional,
567
+ * because a plural entry inherits anything it omits from the shared base.
568
+ * Whether the MERGED entry names a subject, an action and a resource is a
569
+ * cross-object property no per-object schema can carry, and the platform's own
570
+ * projection enforces it server-side.
571
+ *
572
+ * This is deliberately the ONLY thing checked here, and it is checked by
573
+ * PRESENCE alone. Everything else the server refuses — which action names are
574
+ * evaluable, which resource types exist, which correlation keys this deployment
575
+ * records — is deployment state the SDK does not have. A client that guessed at
576
+ * it would refuse requests a newer gateway accepts, and the caller would have
577
+ * no way to tell an SDK that is out of date from a request that is wrong.
578
+ */
579
+ function checkComplete(request, base, at) {
580
+ const missing = ['subject', 'action', 'resource'].filter(member => !request[member] && !(base && base[member]));
581
+ if (missing.length > 0) {
582
+ throw new AuthZENRefusal(authzen_gen_1.AUTHZEN_ERROR_CODE_INCOMPLETE_EVALUATION, `after inheriting from the shared base this evaluation still has no ` +
583
+ `${missing.join(', ')}; there is nothing to evaluate`, { refusedBy: 'client', pointer: at });
584
+ }
585
+ const subject = request.subject ?? base?.subject;
586
+ if (subject && subject.id.trim() === '') {
587
+ throw new AuthZENRefusal(authzen_gen_1.AUTHZEN_ERROR_CODE_INCOMPLETE_EVALUATION, 'the subject id must not be blank; a decision has to name the caller it was made for', { refusedBy: 'client', pointer: `${at}/subject/id` });
588
+ }
589
+ }
590
+ /** Refuse an envelope that cannot produce a decision, before the round trip. */
591
+ function checkEnvelopeComplete(envelope) {
592
+ if (envelope.evaluation) {
593
+ checkComplete(envelope.evaluation, undefined, '/evaluation');
594
+ return;
595
+ }
596
+ if (envelope.evaluations) {
597
+ const bulk = envelope.evaluations;
598
+ const base = {
599
+ subject: bulk.subject,
600
+ action: bulk.action,
601
+ resource: bulk.resource,
602
+ context: bulk.context,
603
+ };
604
+ (bulk.evaluations ?? []).forEach((entry, index) => {
605
+ checkComplete(entry, base, `/evaluations/evaluations/${index}`);
606
+ });
607
+ }
608
+ }
609
+ // ---------------------------------------------------------------------------
610
+ // The response direction
611
+ // ---------------------------------------------------------------------------
612
+ /**
613
+ * Refuse a 200 this build cannot act on.
614
+ *
615
+ * Every check here closes a way for an un-actionable body to be read as an
616
+ * allow. A decoded response that is merely well-typed is not enough: the
617
+ * boolean and the state are two renderings of one outcome, and a build that
618
+ * trusts either alone will act on a decision the other contradicts.
619
+ */
620
+ function validateDecision(response, body) {
621
+ if (!response.context) {
622
+ throw new AuthZENProtocolError(`the server answered without the profile context. This SDK negotiates ` +
623
+ `${authzen_gen_3.AUTHZEN_PROFILE_HEADER}: ${authzen_gen_1.AUTHZEN_PROFILE_V1} on every request, so a response ` +
624
+ `carrying only the boolean means the gateway did not honour the negotiation — an ` +
625
+ `older build, or a proxy that dropped the header. The obligations and the approval ` +
626
+ `challenge that CONSTRAIN an allow ride in that payload, so an allow without it is ` +
627
+ `an allow whose mandatory conditions cannot be read. body=${body}`);
628
+ }
629
+ const context = response.context;
630
+ if (context.profile !== authzen_gen_1.AUTHZEN_PROFILE_V1) {
631
+ throw new AuthZENProtocolError(`the server answered with AuthZEN profile '${context.profile}'; this build can only ` +
632
+ `interpret '${authzen_gen_1.AUTHZEN_PROFILE_V1}'. The obligations and approval challenge that ` +
633
+ `constrain an allow are carried in that payload, so the decision cannot be acted ` +
634
+ `on safely. Upgrade the SDK.`);
635
+ }
636
+ if (!authzen_gen_1.AUTHZEN_OPERATIONAL_STATE_VALUES.includes(context.state)) {
637
+ throw new AuthZENProtocolError(`the server reported the operational state '${context.state}', which this build does ` +
638
+ `not know. Under profile ${authzen_gen_1.AUTHZEN_PROFILE_V1} the state set is closed, so a new ` +
639
+ `value means the response was produced by something this SDK cannot interpret — ` +
640
+ `and a state whose meaning is unknown must not be resolved into permission. ` +
641
+ `body=${body}`);
642
+ }
643
+ const executable = context.state === authzen_gen_1.AUTHZEN_OPERATIONAL_STATE_ALLOW;
644
+ if (response.decision !== executable) {
645
+ throw new AuthZENProtocolError(`the decision boolean (${response.decision}) and the operational state ` +
646
+ `(${context.state}) disagree; exactly one state permits execution, so one of the ` +
647
+ `two renderings of this outcome is wrong and there is no safe way to choose ` +
648
+ `between them. body=${body}`);
649
+ }
650
+ if (!executable && context.obligations && context.obligations.length > 0) {
651
+ throw new AuthZENProtocolError(`the server attached obligations to a ${context.state} decision. Obligations ride ` +
652
+ `only on an executable decision: instructions on a refusal invite an enforcement ` +
653
+ `point to discharge them and proceed. body=${body}`);
654
+ }
655
+ // `schema_version` is deliberately NOT enforced. The PROFILE is the
656
+ // negotiated contract and is checked above; schema_version is carried so a
657
+ // support conversation can name the contract a deployment answered from.
658
+ // Enforcing both would mean the two have to be bumped in lockstep, and this
659
+ // SDK would start refusing decisions over a discrepancy that changes nothing
660
+ // it reads.
661
+ }
662
+ /**
663
+ * Validate the envelope, reporting a schema violation as a TYPED refusal.
664
+ *
665
+ * Shared by `evaluateEnvelope` and `toWire` so the two cannot answer the same
666
+ * malformed envelope differently. `toWire` used to leak the raw
667
+ * `AuthZENSchemaError` while `evaluateEnvelope` converted it, which made the
668
+ * function documented as "the exact document this SDK would send" throw
669
+ * something the send path never throws.
670
+ */
671
+ function validateEnvelopeOrRefuse(resolved) {
672
+ try {
673
+ return (0, authzen_gen_1.validateAuthZENEnvelope)(stripUndefined(resolved), '');
674
+ }
675
+ catch (err) {
676
+ if (!(err instanceof authzen_gen_1.AuthZENSchemaError))
677
+ throw err;
678
+ throw new AuthZENRefusal(authzen_gen_1.AUTHZEN_ERROR_CODE_MALFORMED_ENVELOPE, err.message, {
679
+ refusedBy: 'client',
680
+ pointer: err.pointer,
681
+ });
682
+ }
683
+ }
684
+ /**
685
+ * Decode a structured refusal document, or undefined if the body is not one.
686
+ *
687
+ * Decoded LENIENTLY, unlike the decision path, and the asymmetry is deliberate.
688
+ * Strictness on a DECISION is a safety control: an unknown member means the
689
+ * server is speaking a profile this build cannot fully read, and the unread part
690
+ * may be the one that constrains an allow. A refusal constrains nothing - it
691
+ * says no decision exists - so the same strictness buys no safety and costs the
692
+ * caller the whole point of the surface: one additive field on the refusal
693
+ * envelope would degrade every typed refusal into a bare error, losing the code,
694
+ * the pointer, the supported set and the retryable signal on the one path whose
695
+ * entire purpose is to be branchable.
696
+ *
697
+ * Unknown members are dropped here, and the SHAPE is still checked: a body
698
+ * carrying no code or no message is not a refusal document and returns
699
+ * undefined, which sends the caller down the generic-error path rather than
700
+ * fabricating a refusal the server did not make.
701
+ */
702
+ const AUTHZEN_ERROR_MEMBERS = ['code', 'pointer', 'message', 'supported', 'request_id'];
703
+ function decodeRefusal(body) {
704
+ let parsed;
705
+ try {
706
+ parsed = JSON.parse(body);
707
+ }
708
+ catch {
709
+ return undefined;
710
+ }
711
+ if (typeof parsed !== 'object' || parsed === null || Array.isArray(parsed))
712
+ return undefined;
713
+ const known = {};
714
+ AUTHZEN_ERROR_MEMBERS.forEach(member => {
715
+ const value = parsed[member];
716
+ if (value !== undefined)
717
+ known[member] = value;
718
+ });
719
+ try {
720
+ return (0, authzen_gen_1.validateAuthZENError)(known, '');
721
+ }
722
+ catch {
723
+ return undefined;
724
+ }
725
+ }
726
+ /**
727
+ * Build an envelope: RESOLVE, check completeness, then validate.
728
+ *
729
+ * The counterpart of the Python sibling's `build_envelope`, and it exists for
730
+ * the same reason: `evaluate` and `evaluateAll` must not each assemble an
731
+ * envelope inline, or the two entry points drift on the order these steps run
732
+ * in - and that order decides which of two problems a caller with two problems
733
+ * is told about.
734
+ */
735
+ function buildEnvelope(evaluation, evaluations) {
736
+ const envelope = {};
737
+ if (evaluation !== undefined)
738
+ envelope.evaluation = evaluation;
739
+ if (evaluations !== undefined)
740
+ envelope.evaluations = evaluations;
741
+ const resolved = resolveEnvelope(envelope);
742
+ if (resolved.evaluation === undefined || resolved.evaluations === undefined) {
743
+ checkEnvelopeComplete(resolved);
744
+ }
745
+ assertFullyResolved(resolved);
746
+ return validateEnvelopeOrRefuse(resolved);
747
+ }
748
+ /**
749
+ * Run one envelope through `send` and interpret the answer.
750
+ *
751
+ * `send` is the SDK's own transport — the same authenticated fetch wrapper,
752
+ * headers and heartbeat gate every other method uses. It is passed in rather
753
+ * than built here so this module owns the AuthZEN semantics and nothing else; a
754
+ * second transport would be a second place for credentials, timeouts and proxy
755
+ * configuration to drift out of step with the client the user configured.
756
+ */
757
+ async function evaluateEnvelope(send, envelope) {
758
+ const resolved = resolveEnvelope(envelope);
759
+ // Completeness runs FIRST, so a missing subject/action/resource is reported
760
+ // as `incomplete_evaluation` for both envelope shapes. The generated
761
+ // validator would otherwise reach the singular member's own required set
762
+ // first and report the same mistake under a different code depending on
763
+ // which shape the caller used.
764
+ //
765
+ // Except when the envelope names BOTH members: its fault is not that an
766
+ // evaluation is incomplete, and answering "no action" for a request whose
767
+ // real problem is that it asks two questions at once sends the caller to the
768
+ // wrong member entirely.
769
+ if (resolved.evaluation === undefined || resolved.evaluations === undefined) {
770
+ checkEnvelopeComplete(resolved);
771
+ }
772
+ assertFullyResolved(resolved);
773
+ const wire = validateEnvelopeOrRefuse(resolved);
774
+ const { status, body } = await send(authzen_gen_3.AUTHZEN_PATH, wire, {
775
+ [authzen_gen_3.AUTHZEN_PROFILE_HEADER]: authzen_gen_1.AUTHZEN_PROFILE_V1,
776
+ });
777
+ if (status === 401) {
778
+ // Authentication is answered by the gateway's own middleware, before the
779
+ // route runs, so it never carries an AuthZEN refusal document. Surfacing it
780
+ // as the SDK's existing AuthenticationError keeps one error for "your
781
+ // credentials are wrong" across every method on this client, instead of a
782
+ // second one only AuthZEN callers know to catch.
783
+ throw new errors_1.AuthenticationError(`Invalid credentials for ${authzen_gen_3.AUTHZEN_PATH}: ${body}`);
784
+ }
785
+ if (status !== 200) {
786
+ const refusal = decodeRefusal(body);
787
+ if (refusal)
788
+ throw AuthZENRefusal.fromBody(refusal);
789
+ // A non-OK body that is not a refusal document still surfaces as an error —
790
+ // never as a decision.
791
+ throw new errors_1.AxonFlowError(`HTTP ${status} from ${authzen_gen_3.AUTHZEN_PATH}: ${body}`);
792
+ }
793
+ let parsed;
794
+ try {
795
+ parsed = JSON.parse(body);
796
+ }
797
+ catch (err) {
798
+ throw new AuthZENProtocolError(`the decision could not be decoded: ${err.message}. body=${body}`);
799
+ }
800
+ let response;
801
+ try {
802
+ // Strict decoding on the success path. An unknown member in a decision is a
803
+ // server speaking a profile this build does not understand, and quietly
804
+ // dropping it would mean acting on a partial reading of an authorization
805
+ // decision. A TypeScript cast would do none of this — the interface is
806
+ // erased at runtime — which is why the validator is generated.
807
+ response = (0, authzen_gen_1.validateAuthZENResponse)(parsed, '');
808
+ }
809
+ catch (err) {
810
+ throw new AuthZENProtocolError(`the decision could not be decoded: ${err.message}. body=${body}`);
811
+ }
812
+ validateDecision(response, body);
813
+ return new AuthZENDecision(response);
814
+ }
815
+ /**
816
+ * Drop `undefined` members so they are not serialised as `null`.
817
+ *
818
+ * `JSON.stringify` already omits an `undefined` property, but the generated
819
+ * validator runs BEFORE serialisation and would otherwise see the key present
820
+ * with an undefined value. Normalising here means the validator, the bytes on
821
+ * the wire and `toWire` below all describe the same document.
822
+ */
823
+ function stripUndefined(value) {
824
+ if (Array.isArray(value))
825
+ return value.map(stripUndefined);
826
+ if (typeof value === 'object' && value !== null) {
827
+ const out = {};
828
+ Object.entries(value).forEach(([key, item]) => {
829
+ if (item === undefined)
830
+ return;
831
+ // defineProperty for the same reason as the resolver: a plain assignment
832
+ // to the key `__proto__` invokes the inherited setter instead of creating
833
+ // a member, so the member would be dropped HERE even after the resolver
834
+ // carried it through. Two places, one rule.
835
+ Object.defineProperty(out, key, {
836
+ value: stripUndefined(item),
837
+ writable: true,
838
+ enumerable: true,
839
+ configurable: true,
840
+ });
841
+ });
842
+ return out;
843
+ }
844
+ return value;
845
+ }
846
+ /**
847
+ * Guarantee no tri-state attribute reaches the wire.
848
+ *
849
+ * `resolveEnvelope` walks every bag the contract declares, so on today's
850
+ * contract this has nothing to catch. It exists for the case that does not
851
+ * announce itself: a container kind added to the artifact later, or an attribute
852
+ * reaching a member the resolver does not visit. Without it that attribute is
853
+ * not a crash - `JSON.stringify` turns the instance into an ordinary
854
+ * `{"state": …, "value": …, "reason": …}` object - so the request is SENT,
855
+ * carrying a resolver's internal shape where the gateway expects a value, and an
856
+ * UNKNOWN attribute reaches the network after all.
857
+ *
858
+ * The Python sibling carries the same control, and had exactly this defect:
859
+ * there the check ran after serialisation and could never fire.
860
+ */
861
+ function assertFullyResolved(value, path = '', depth = 0) {
862
+ if (depth > MAX_ATTRIBUTE_DEPTH) {
863
+ // Bounded for the same reason the resolver is, and by the same number. Two
864
+ // walkers that disagree on their bound is how a cycle reaching only the
865
+ // unbounded one comes back as a RangeError - the error type the bound
866
+ // exists to remove.
867
+ throw new AuthZENProtocolError(`the structure at ${path || '/'} nests deeper than ${MAX_ATTRIBUTE_DEPTH} levels; ` +
868
+ `this SDK will not walk it, and a structure that refers to itself would ` +
869
+ `otherwise recurse until the engine stopped`);
870
+ }
871
+ if (AuthZENAttribute.is(value)) {
872
+ throw new AuthZENProtocolError(`an unresolved AuthZENAttribute reached the wire at ${path || '/'}. Tri-state ` +
873
+ `attributes are only supported inside the context and properties bags; this one is ` +
874
+ `somewhere the resolver does not reach.`);
875
+ }
876
+ if (Array.isArray(value)) {
877
+ value.forEach((item, index) => assertFullyResolved(item, `${path}/${index}`, depth + 1));
878
+ return;
879
+ }
880
+ if (typeof value === 'object' && value !== null) {
881
+ Object.keys(value).forEach(key => {
882
+ assertFullyResolved(value[key], `${path}/${escapePointerToken(key)}`, depth + 1);
883
+ });
884
+ }
885
+ }
886
+ /**
887
+ * The exact document this SDK would send for `envelope`.
888
+ *
889
+ * Exported for tests and for support: "what did the SDK actually put on the
890
+ * wire" is the first question of every integration problem, and answering it by
891
+ * reading the client's source is how the answer ends up wrong.
892
+ */
893
+ function toWire(envelope) {
894
+ const resolved = resolveEnvelope(envelope);
895
+ if (resolved.evaluation === undefined || resolved.evaluations === undefined) {
896
+ checkEnvelopeComplete(resolved);
897
+ }
898
+ assertFullyResolved(resolved);
899
+ return validateEnvelopeOrRefuse(resolved);
900
+ }
901
+ //# sourceMappingURL=authzen.js.map