Repository navigation
Hub 0.19.2 moves the
@authup/*libraries to1.0.0-beta.72and picks up the minor and patch updates of the tooling and runtime dependencies. Unlike v0.19.1, this one raises the Authup server requirement: deploy it together with an Authup server on1.0.0-beta.72.
👀 Highlights
🔐 Upgrade Hub and the Authup server together
beta.72 changed the shape of the two Authup endpoints Hub's authorization depends on. GET /authorization, the catalog every Hub service reads per request, is now camelCase (realmId, clientId, decisionStrategy), and @authup/access rejects the old shape. POST /authorization/check, the batch behind every client-ui permission gate, changed as well.
A mixed deployment fails closed, not partially:
| Hub | Authup server | Result |
|---|---|---|
| 0.19.2 | beta.72 | Works |
| 0.19.2 | beta.70 / beta.71 | Services reject the catalog, every authenticated request fails, every UI gate denies |
| ≤ 0.19.1 | beta.72 | Same, in the other direction |
Warning
Roll out the Authup server and every Hub service plus client-ui in the same window. There is no order in which one side can run ahead.
🌐 Hub's permissions stay global, and realm-less admin objects now are too
POST /authorization/check now also resolves permissions owned by a realm or a client. A check by bare name still matches the global definition only, and Hub adds no fallback to the session realm: such a fallback would let a realm-owned copy named analysis_create count as Hub's permission. Keep provisioning Hub's permission names without a realmId, as before.
The other side of the same change: roles, permissions, scopes and policies created without a realmId are now global, where they used to land in the creator's realm. In the client-ui admin pages, the Authup forms fill in the realm for a realm admin. A master user who creates a permission now creates a global one, which is the one Hub checks.
Note
Hub's services create only clients (always with a realmId) and client-permission links, so the node-client and analysis-client provisioning is unaffected.
🧩 One @vueuse/core again
v0.19.1 left @vuecs/* and @ilingo/* on @vueuse/core 14 while Hub's packages moved to 15. This release raises ilingo / @ilingo/* and @vuecs/design, @vuecs/locale and @vuecs/theme-tailwind to the releases that accept 15, so @vueuse/core 15 is hoisted to the top level. The remaining 14.x copies come in only as plain dependencies of @vuecs/forms, @vuecs/nuxt and reka-ui.
Tip
If you consume @privateaim/client-vue alongside @vuecs/* or @ilingo/*, raise those to their latest releases too, so your app resolves one @vueuse/core as well.
⚠️ Heads-Up Before Upgrading
| Change | What to do |
|---|---|
Authup server 1.0.0-beta.72 required |
Upgrade the Authup server in the same rollout as all Hub services and client-ui |
| Realm-less roles, permissions, scopes and policies are global | Check admin scripts or runbooks that relied on the creator's realm being filled in implicitly |
⬆️ Upgrading
npm install @privateaim/core-http-kit@^0.19.2 # and any other @privateaim/* package you useFor the services and client-ui, deploy the 0.19.2 image together with Authup 1.0.0-beta.72. No database migration or Hub configuration change is needed. If you are coming from v0.18.x, follow the upgrade order in the v0.19.0 release notes first, and read the Authup upgrade guide for the server side.
👉 Changelog
Full diff: v0.19.1...v0.19.2