Permissões e limites de confiança
Interseção manifesto/host, identidades revogáveis, papéis de UI e controles diferentes para plugins, IA e servidor.
Veja versões, mudanças e requisitos em Framework 4.0 e CLI 1.2.
Autoridade efetiva
WU calcula permissões como a interseção entre solicitações do manifest e grants do shell. Sem solicitações ou grants, a app não recebe capacidades técnicas. Adicionar um grant que a app não pediu também não amplia sua autoridade.
{
"name": "cart",
"entry": "assets/cart.js",
"wu": {
"permissions": [
{ "capability": "store.read", "resource": "cart", "required": true },
{ "capability": "store.write", "resource": "cart.items", "required": true },
{ "capability": "events.emit", "resource": "cart:changed" }
]
}
}await wu.init({
apps: [{
name: 'cart',
url: '/apps/cart',
grants: [
{ capability: 'store.read', resource: 'cart' },
{ capability: 'store.write', resource: 'cart.items' },
{ capability: 'events.emit', resource: 'cart:changed' },
],
}],
});required: true exige cobertura completa para registrar a app. Uma solicitação opcional pode ser negada ou coberta parcialmente; a política mantém diagnósticos. Ser opcional não significa que será autorizada na primeira chamada.
Capacidades técnicas permitidas
| Capacidade | Operação |
|---|---|
events.emit |
Emitir fatos nos recursos concedidos |
events.subscribe |
Inscrever-se em eventos permitidos |
rpc.provide |
Fornecer handlers do barramento e contratos de métodos |
rpc.call |
Solicitar respostas e consumir contratos |
store.read |
Ler, obter snapshots e inscrever-se em caminhos |
store.write |
Escrever e fazer batch em caminhos |
drag.offer |
Oferecer dados de um tipo durante um arraste |
drag.accept |
Aceitar dados de um tipo em um destino |
store.update precisa de leitura e escrita. Não existem concessões arbitrárias device.*, deploy.* ou build.*; a lista é fechada em wu-policy.js.
Os recursos usam strings exatas ou um wildcard final. No store, o curinga deve ocupar um segmento completo, como cart.*. wu:, system: e app: são namespaces reservados para emissão e fornecimento/chamadas RPC. Uma solicitação events.emit:* se sobrepõe a eles e não é uma forma válida de conceder toda a autoridade do host.
Identidade durante o ciclo de vida
O core cria uma lease por aplicação e entrega uma fachada congelada. Cada método verifica se essa lease continua ativa; as funções adicionam a identidade correta sem aceitar que uma app se torne outra alterando appName.
Ao desmontar, as fachadas são revogadas e os recursos associados são limpos. Os contratos consumidos pela fachada também são envolvidos para falhar após a revogação. Uma variável global que mantém uma fachada antiga não recupera autoridade quando uma app com o mesmo nome é montada novamente: uma nova identidade de ciclo de vida é criada.
Os hooks de eventos/store dos treze adapters respeitam a facade da app no 4.0. Isso protege chamadas cooperativas, mas module compartilha o realm e pode alcançar o host. Shadow DOM e sandboxes de mesma origem não contêm código hostil; use uma app remota em outra origem para essa fronteira.
Quatro controles diferentes
| Controle | O que decide | O que não decide |
|---|---|---|
| Concessões técnicas WU | Uso do barramento, RPC e caminhos do store | Acesso aos dados do backend |
setPrincipal / papéis |
Se uma app pode ser montada na UI | Autorização confiável do usuário no servidor |
| Permissões de plugins | Quais métodos sua API de instalação oferece | Contenção de código que já é executado no host |
| Flags de IA | Leitura, escrita, DOM, rede ou execução de actions de IA | Permissões de domínio de uma operação remota |
A configuração de plugins usa outra lista: mount, events, store, apps, config, unsafe. O host deve conceder explicitamente as permissões solicitadas. As actions de IA usam flags como executeActions, writeStore e network. Nenhuma lista pode ser usada no lugar de outra.
Fronteira do servidor
Credenciais, acesso a recursos, idempotência e auditoria durável pertencem a um serviço autenticado. Um handler de action é código do host e pode capturar fetch ou um cliente privilegiado em uma closure; a API fornecida ao handler não pode conter essa closure.
Para operações com efeitos, projete um gateway que valide identidade, parâmetros, escopo, política e aprovação antes de executar. Timeline e store não desfazem envios, pagamentos, builds ou alterações de infraestrutura. Se o domínio permitir desfazer, uma compensação explícita deve ser implementada.
O subcaminho wu-framework/server oferece createNonce, securityHeaders, buildCsp, middleware e wrappers de resposta. Esses helpers constroem cabeçalhos; sua instalação real cabe ao servidor que entrega a página e os assets.
Migração controlada
await wu.init({
compatibility: { profile: 'compat-v2', warnings: 'once' },
apps: [],
});
console.table(wu.compatibility.getMigrationReport());O perfil compat-v2 habilita pontes específicas para eventPermissions, concessões implícitas de plugins e execução implícita de actions de IA. É uma migração explícita com diagnóstico; não deve se tornar a configuração base de uma nova app. strictEvents: false também é uma saída deliberada para código confiável e reduz as verificações do barramento.
Referência de implementação
Política: src/core/wu-policy.js, src/core/wu-policy.js, src/core/wu-policy.js; leases: src/core/wu-core.js e src/core/wu-core.js; plugins: src/core/wu-plugin.js; padrões de IA: src/ai/wu-ai-permissions.js; compatibilidade: src/core/wu-compatibility.js. Testes: tests/unit/capability-security-v3.test.js, tests/unit/plugin-security.test.js, tests/unit/security-regressions.test.js, tests/security/compatibility-boundaries.test.js.