Notificações
O Libre WebUI mantém uma caixa de entrada de notificações persistente por usuário para que atividades da equipe — menções, mensagens diretas, compartilhamentos, falhas de automações e lembretes de calendário — cheguem às pessoas mesmo quando a página correspondente estiver fechada.
A caixa de entrada
As notificações são primeiro linhas do banco de dados: título e corpo criptografados em repouso, limite de 500 por usuário (as mais antigas são removidas) e desduplicação por uma chave de origem opcional, para que publicações repetidas sejam consolidadas em uma só entrada em vez de lotarem o sino. A interface RESTful lista, conta as não lidas, marca uma ou todas como lidas e exclui.
A entrega ao vivo usa o fluxo persistente de eventos por usuário notify:<userId> por meio de GET /api/notifications/events (SSE). A identidade do fluxo vem da sessão autenticada — nunca de dados fornecidos pelo cliente — e a caixa de entrada SQL continua sendo a fonte da verdade: um evento perdido é recuperado pela leitura da lista, não pela reprodução do fluxo.
O que gera notificações
| Tipo | Quando é gerada |
|---|---|
channel-dm | Alguém envia uma mensagem direta a você |
channel-mention | Alguém usa @mentions para mencionar você em um canal ou responde à sua mensagem |
channel-invite | Você é adicionado a um canal |
share | Alguém compartilha um recurso com você |
automation-failed | Uma de suas automações falha (a menos que tenha desativado a opção) |
calendar-reminder | Um evento com lembrete atinge o horário definido |
work-run-finished | Um dos agentes do Work que você contratou conclui uma execução |
work-run-attention | Um agente contratado para e aguarda dados ou encontra um erro |
work-takeover | Um agente do Work pede que você assuma o controle da tela |
work-approval | Uma execução do Work aguarda sua aprovação de uma ação com efeito colateral |
system | Comunicados no nível da instância |
As notificações sempre são publicadas somente para o usuário afetado; mencionar o nome de usuário de alguém que não é membro do canal não gera nada.
Webhooks de saída
Administradores podem cadastrar destinos de webhook para receber eventos da equipe.
- Saída protegida. Os destinos seguem a mesma política aplicada a servidores de ferramentas: URL exata, sem redirecionamentos e sem endereços privados ou link-local, a menos que o administrador inclua explicitamente um host na lista de permissões por meio de
TOOLS_PRIVATE_NETWORK_ALLOWLIST. Os nomes de host são resolvidos e verificados novamente em cada entrega. - Assinados. Quando há um segredo configurado, toda entrega inclui
X-Libre-Signature: sha256=<hmac>, calculado sobre o corpo exato. - Com dados suprimidos. O envelope contém o tipo de evento, o tipo e o título da notificação, identificadores e carimbos de data e hora. Corpos de notificações, conteúdo de mensagens, prompts e documentos nunca saem da instância.
- Persistentes. As entregas são executadas como tarefas persistentes com tentativas limitadas; uma resposta 5xx do destinatário gera uma nova tentativa, enquanto uma resposta 4xx é tratada como a decisão do destinatário e encerra a entrega.
- Com escopo. Cada destino assina tipos específicos de notificação (ou
*).
Push no navegador
Configurações → Notificações cadastra este navegador para Web Push, permitindo que menções, compartilhamentos, lembretes e trabalhos concluídos cheguem ao dispositivo mesmo quando a aba estiver fechada. A implementação é padrão e autocontida:
- VAPID (RFC 8292). O servidor assina cada entrega com um par de chaves ES256, gerado uma vez e armazenado de forma criptografada, ou fixado com
VAPID_PUBLIC_KEY/VAPID_PRIVATE_KEY(VAPID_SUBJECTdefine a declaração de contato). Nenhuma biblioteca de push de terceiros nem conta de serviço participa além do endpoint de push do fornecedor do navegador. - Cargas criptografadas (RFC 8291). Toda mensagem é criptografada para as chaves do próprio dispositivo com aes128gcm antes de sair da instância; o serviço de push retransmite um texto cifrado que não consegue ler.
- Por dispositivo e vinculada à sessão. Uma assinatura pertence ao navegador que a criou e à sessão de autenticação desse navegador: encerrar a sessão (ou “sair de outras sessões”) também remove seu cadastro de push. Os endpoints são armazenados criptografados com um token de consulta com chave e devem ser destinos HTTPS públicos — a mesma higiene de saída aplicada aos webhooks.
- Persistentes. As entregas push são executadas como tarefas persistentes com tentativas limitadas; se um serviço de push informar que a assinatura não existe mais (404/410), ela será removida.
- A carga contém o título da notificação, corpo opcional, tipo e link de destino — a mesma postura de supressão de dados da caixa de entrada.
O push exige o aplicativo de produção (o service worker é cadastrado somente nele) e uma origem segura. O shell offline e a possibilidade de instalação vêm do mesmo service worker: o manifesto do aplicativo torna o Libre WebUI instalável, as navegações usam o shell em cache quando estão offline e os ativos de build com hash são armazenados de forma imutável. O tráfego da API nunca é armazenado em cache.
Limites funcionais
- Preferências de usuário por tipo ainda não estão implementadas; as automações respeitam sua própria configuração de notificação, e sair de um canal interrompe suas notificações.