v4.9.0

Quem só precisa LER as permissões não cobra mais poder de ESCRITA.

Atualizar não muda nada para quem roda com
archbase.security.admin-endpoints.policy=permit — que é o padrão do
framework. Muda para quem endureceu a política, e é justamente quem estava
quebrado.

O DEFEITO

ArchbaseSecurityManager.apply() chamava POST /resource/register para TODO
usuário ao abrir cada tela. Esse endpoint escreve o catálogo de segurança e o
backend o marca como administrativo — então, com admin-only, todo não-admin
tomava 403 em toda tela: permissions ficava vazio, hasPermission respondia
false para tudo, e o menu inteiro aparecia desabilitado. Conceder a permissão no
banco não mudava nada, porque a resposta que a carregaria nunca chegava.

POR QUE ISTO NÃO ERA APENAS UMA TELA CINZA

Dois projetos independentes reagiram do mesmo jeito: voltaram a política para
permit para destravar o produto. E permit deixa qualquer autenticado
alcançar CRIAR USUÁRIO e CONCEDER PERMISSÃO — quem se promove a gestor atravessa
depois todas as demais guardas legitimamente. Um método que só precisava ler
estava cobrando poder de escrita, e o preço foi pago afrouxando a autorização
inteira.

A SEPARAÇÃO JÁ EXISTIA NO BACKEND

GET /resource/permissions/{recurso} é marcado selfService e devolve o mesmo
ResourcePermissionsDto do registro. Faltava só o método no
ArchbaseResourceService. Agora o administrador registra — que é quando o
catálogo de fato precisa ser escrito — e os demais leem o que podem.

Não exige atualizar o backend: a marcação selfService nessa rota entrou na
3.1.0 do archbase-app-framework, e a correção foi verificada contra um servidor
rodando 3.1.22, com token de usuário VENDEDOR — 200 na leitura, 403 no register.

POR QUE MINOR, E NÃO PATCH

O contrato de QUANDO o catálogo é escrito mudou. O catálogo de um recurso passa
a nascer quando um administrador abre aquela tela. Tela que nenhum admin abre
não tem ação cadastrada, e sem ação cadastrada não há o que conceder. É o
comportamento correto — o catálogo descreve o sistema, não quem passou por ele —
mas quem esconde telas do admin por papel precisa saber que está escondendo
também o registro delas. Há também um método público novo,
ArchbaseResourceService.findLoggedUserResourcePermissions().

VERIFICAÇÃO

4 testes novos em @archbase/security, com o controle do admin de propósito:
sem ele, trocar as duas chamadas por leitura em todos os casos também passaria,
e o catálogo nunca mais seria escrito por ninguém — mesmo sintoma, causa oposta.

Packages

• @archbase/core
• @archbase/data
• @archbase/components
• @archbase/layout
• @archbase/admin
• @archbase/advanced
• @archbase/security
• @archbase/security-ui
• @archbase/template
• @archbase/tools
• @archbase/feature-flags
• @archbase/ssr

Installation

npm install @archbase/core@4.9.0

Documentation

Visit https://react.archbase.dev for full documentation.

Full Changelog: v4.8.0...v4.9.0