@canopy-io/nestjs 0.5.0 → 0.6.1

package/CHANGELOG.md

@@ -1,5 +1,25 @@
 # @canopy-io/nestjs
 
+## 0.6.1
+
+### Patch Changes
+
+- Updated dependencies [51fd41e]
+  - @canopy-io/node@0.13.0
+
+## 0.6.0
+
+### Minor Changes
+
+- 10d3583: Organization membership is admission, not a role. Identity tokens carry `org_roles` (the names of the roles held at the organization node, sorted, possibly empty) in place of `org_role`; `orgContext(claims)` returns `{ orgId, orgRoles }`, and refuses a token carrying one claim without the other. An empty `orgRoles` is a member holding no role at the organization node, so authorize by evaluating rather than by the list. The conformance bundle gains the `organization-membership` vector: a grant inside an organization counts only while the membership is active, which the grants `LocalAuthorizer` caches already reflect.
+  
+  `organizations.changeMemberRole()` is gone with its route: a member's role at the organization is an assignment at the organization node, written through `assignments.create()`, `assignments.update()` and `assignments.delete()` with the organization node as `node_id`. `assignments.update()` takes `{ ifMatch }` and sends it as `If-Match`; a stale version answers `409 assignment.version_mismatch`. `organizations.removeMember()` deactivates the membership and revokes every role the member held in the organization. Member rows carry `status`, `source`, `joined_at` and `roles[]` in place of the single `role`.
+
+### Patch Changes
+
+- Updated dependencies [10d3583]
+  - @canopy-io/node@0.12.0
+
 ## 0.5.0
 
 ### Minor Changes

package/README.md

@@ -112,12 +112,13 @@ The default is `node`, which is the strict question: does this identity hold the
 ```
 
 `org` is for Environments with the **organizations** container on, where a
-token carries the organization the session is acting in (`org_id`) and the one
-role held there (`org_role`). The guard reads `org_id` off the verified claims
-`CanopyTokenGuard` attached and evaluates at that node — an organization _is_ a
-hierarchy node, and a membership is a role assignment at it, so no `resolveNode`
-and no node in the route's path are needed. A caller acting in no organization
-is denied: an org-scoped route has no meaning outside one.
+token carries the organization the session is acting in (`org_id`) and the
+roles held at its node (`org_roles`, possibly none). The guard reads `org_id`
+off the verified claims `CanopyTokenGuard` attached and evaluates at that node —
+an organization _is_ a hierarchy node, and a member's roles are assignments at
+it or beneath it, so no `resolveNode` and no node in the route's path are
+needed. A caller acting in no organization is denied: an org-scoped route has
+no meaning outside one.
 
 If your own auth layer verifies tokens and parks the claims somewhere other
 than `attachTokenAs`, configure `resolveOrg` — and feed it only a value read

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@canopy-io/nestjs",
-  "version": "0.5.0",
+  "version": "0.6.1",
   "description": "Official NestJS integration for Canopy \u2014 hierarchical identity and access management.",
   "license": "MIT",
   "author": "Canopy Identity Inc.",
@@ -62,7 +62,7 @@
     "test:watch": "vitest"
   },
   "dependencies": {
-    "@canopy-io/node": "^0.11.0"
+    "@canopy-io/node": "^0.13.0"
   },
   "peerDependencies": {
     "@nestjs/common": "^10.0.0 || ^11.0.0",