@oondemand/create-central-oon 0.7.9 → 0.7.11
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.
|
@@ -10,7 +10,7 @@ Ativação de plataforma cria a identidade operacional usada por integrações a
|
|
|
10
10
|
|
|
11
11
|
Todo App com RBAC declarado expõe `GET /core/role-catalog`. O contrato `schemaVersion: 1` contém `appCode`, `enabled` e `roles[]` com `code`, `name`, `description` e `admin`. Desde o SDK 0.7.1, a extensão aditiva opcional `roles[].commercialPermissions` publica nomes explícitos de permissões funcionais permitidas pelo papel. Wildcards são expandidos somente pelas permissões declaradas em `rbac.permissions`; wildcard literal e namespaces `tenant`, `publications`, `homologation`, `production`, `apps`, `users` e `roles` são excluídos. Políticas internas e permissões técnicas não são publicadas.
|
|
12
12
|
|
|
13
|
-
O campo permanece opcional no schemaVersion 1: catálogos anteriores são conformes para descoberta e fluxos existentes.
|
|
13
|
+
O campo permanece opcional no schemaVersion 1: catálogos anteriores são conformes para descoberta e fluxos existentes. Todos os novos comandos comerciais de concessão, convite, edição, reativação e aceite inicial requerem essa capacidade e deve falhar fechado com `APP_ROLE_CATALOG_UNAVAILABLE` quando ausente; não se infere autoridade do nome admin. Consumidores antigos devem tolerar campos adicionais. O runtime continua intersectando cada grant explícito com a política local atual.
|
|
14
14
|
|
|
15
15
|
O catálogo serve para descoberta e seleção de perfis pelo Control Plane. Ele não concede acesso: o backend consumidor deve validar `schemaVersion` e `appCode`, consultar somente o Deployment resolvido pela plataforma, revalidar o perfil antes de persistir o grant e falhar fechado quando o catálogo estiver ausente ou inválido.
|
|
16
16
|
|
|
@@ -37,3 +37,41 @@ do storage e não consomem o parâmetro reservado `tenant`. Cockpits globais
|
|
|
37
37
|
devem transportar a organização administrada com um identificador próprio,
|
|
38
38
|
como `targetTenantId`, e o BFF deve convertê-lo no header específico do
|
|
39
39
|
contrato administrativo. Esse alvo nunca integra a sessão do App.
|
|
40
|
+
|
|
41
|
+
|
|
42
|
+
## Ambientes de Apps licenciados single-tenant
|
|
43
|
+
|
|
44
|
+
O proprietário A mantém os deployments canônicos de Dev/HML/Produção. Produção
|
|
45
|
+
usa o tenant de dados B; Dev/HML usam o tenant de dados A, tanto para membros de A
|
|
46
|
+
quanto para usuários autorizados de B. Isso não cria membership de B em A.
|
|
47
|
+
`usuario.tenantId`, `tenant.id` e `req.accessContext.tenantId` são o contexto de
|
|
48
|
+
dados. `authorizationTenantId` identifica a organização da concessão; em um
|
|
49
|
+
acesso comercial de B a Dev/HML ele continua sendo B. O ator vem da sessão,
|
|
50
|
+
o proprietário do App e o deployment da credencial operacional do backend.
|
|
51
|
+
|
|
52
|
+
A Central revalida licença, grant, política e revisão do ambiente em cada
|
|
53
|
+
requisição protegida. Campos assinados incluem App, deployment, ambiente,
|
|
54
|
+
`appLicenseId/appLicenseVersion`, `grantId/grantType/grantVersion`,
|
|
55
|
+
`authorizationTenantId`, `functionalTenantId` e `environmentRevision`.
|
|
56
|
+
O Core não replica essa política nem mantém cache positivo de autorização.
|
|
57
|
+
Use apenas o `accessContext` confirmado para filtros e mutações de dados.
|
|
58
|
+
|
|
59
|
+
Dev/HML são fechados para B por padrão e exigem liberação independente de A,
|
|
60
|
+
licença e concessão individual. Dev funcional não exige nem concede publicação.
|
|
61
|
+
Retirar HML invalida suas próximas autorizações e launches sem alterar a revisão
|
|
62
|
+
de Produção. Reliberar não recupera sessões antigas ou grants revogados.
|
|
63
|
+
A opera Dev/HML sob seus próprios grants, sem suporte de B. Produção exige grant
|
|
64
|
+
de B ou suporte explícito, temporário e revogável. Publicação, promoção, rollback
|
|
65
|
+
e aceite técnico de HML permanecem exclusivos de A com permissão técnica.
|
|
66
|
+
|
|
67
|
+
O login direto recebe uma seleção de organização somente para resolver a
|
|
68
|
+
concessão. Desde a correção preparada em 0.7.10, login e launch validam o token
|
|
69
|
+
sem header de tenant anterior e só depois persistem token e tenant de dados
|
|
70
|
+
confirmados. Logout, falha ou tentativa substituta descartam a sessão pendente.
|
|
71
|
+
Não decodifique claims no navegador para autorizar acesso. Uma requisição
|
|
72
|
+
protegida com header diferente do tenant de dados confirmado é recusada.
|
|
73
|
+
|
|
74
|
+
Adotar o frontend corrigido requer publicar o SDK e republicar os runtimes.
|
|
75
|
+
Não adaptar regras de negócio do App ou editar snapshots `.ooncore` à mão.
|
|
76
|
+
Apps próprios/globais conservam seus contratos; Apps comerciais antigos serão
|
|
77
|
+
recriados pelo responsável operacional, sem migração ou fallback autorizador.
|
package/package.json
CHANGED
|
@@ -11,7 +11,7 @@
|
|
|
11
11
|
"sync:metadata": "oonCore-front sync:metadata"
|
|
12
12
|
},
|
|
13
13
|
"dependencies": {
|
|
14
|
-
"@oondemand/oon-core-front": "^0.7.
|
|
14
|
+
"@oondemand/oon-core-front": "^0.7.11",
|
|
15
15
|
"@chakra-ui/react": "^3.13.0",
|
|
16
16
|
"@emotion/react": "^11.14.0",
|
|
17
17
|
"@tanstack/react-query": "^5.65.0",
|