# 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](/pt/docs/guides/releases/).
## 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.
```json
{
"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" }
]
}
}
```
```js
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
```js
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`.