Última versão (detalhamento)

v3.1.2.7 - 06/07/2025

AVISO: FAÇA UM SNAPSHOT DO SERVIDOR

Antes de iniciar qualquer procedimento de atualização, é mandatório criar um snapshot (um ponto de restauração) do seu servidor VPS.

Um snapshot é a sua única garantia de que poderá reverter o sistema ao estado anterior de forma rápida e segura em caso de qualquer falha ou imprevisto durante o processo de atualização.

BREAKING CHANGE

1- Para usuários BAILEYS: Atualize fora do horário de expediente, versão da Baileys atualizada. Pode ser necessário reler o QRCode ou recriar o canal. Nessa versão alteramos o pacote da Baileys, portanto, instabilidades poderão acontecer nos primeiros momentos com essa API Não Oficial

2- Atualizar para 3.1.2.0 ou superior > Atualizar quasar.conf.js (caso realize atualização automática) > acessar a VPS com deployzdg > alterar o arquivo quasar.conf.js na pasta frontend > cd zpro.io && cd frontend && export NODE_OPTIONS=--openssl-legacy-provider && npx quasar build -P -m pwa > pm2 restart all

MUDANÇAS DA VERSÃO

Adicionado:

Limitação para resincronia de mensagens já recebidas com WWEBJS

Detalhamento da função adicionada

O sistema agora verifica se uma mensagem já existe no banco de dados antes de processá-la, ignorando sinais incorretos de "mensagem não lida" enviados pela biblioteca e evitando a duplicação de mensagens.

Ajustado:

Liberação da pasta Public + CORS para Webchat nativo (sem necessidade de liberação do parâmetro SECURE_URL)

Detalhamento da política CORS

📌 Contexto da Política CORS no ZPRO A partir das últimas versões, foi implementada uma política de segurança CORS no backend da ZPRO. O objetivo é restringir o acesso entre origens (URLs de frontend/backend/etc) e impedir que domínios não autorizados consumam os recursos da API ou acessem arquivos da pasta pública.

⚙️ Detalhes da Configuração de CORS No app.ts, definimos uma lista de origens permitidas (allowedOrigins), normalmente com base no .env, como FRONTEND_URL, BACKEND_URL, WSS_URL, e outros localhosts: A configuração permite requisições apenas dessas origens. Quando uma requisição é feita, o origin do navegador é comparado com essa lista. Se for permitido, a requisição segue. Caso contrário, um erro de CORS é retornado: Além disso, usamos: credentials: true → permite envio de cookies/autenticações. allowedHeaders e exposedHeaders → controlam quais cabeçalhos podem ser enviados e exposto

🔐 Sobre a Pasta Pública (/public) Para proteger o acesso a arquivos enviados (mídias, documentos etc), a rota /public também foi encapsulada com regras personalizadas:

✅ Casos em que o acesso à /public é liberado: Quando o domínio de origem está na allowedOrigins. Quando o Referer começa com uma URL permitida. Quando há um x-custom-header ou token igual à chave JWT_REFRESH_SECRET. Quando o agente for do Facebook (para garantir o carregamento de links compartilhados).

🌐 Uso de SECURE_URL=* Se SECURE_URL=* estiver definido no .env, todas as origens são aceitas sem restrições. Isso desativa o filtro de segurança da pasta /public.

❗️ Importante A política se baseia na origem (origin) da requisição, não em certificados. Nenhuma validação de certificado HTTPS está envolvida na lógica do CORS. O problema ocorre geralmente quando a origem da requisição (por exemplo, de um sistema externo ou outro domínio) não consta em allowedOrigins ou não passa nos critérios de validação da /public.

✅ O que fazer se estiver enfrentando erro de CORS? Verifique se a origem da aplicação que está fazendo a requisição está listada em allowedOrigins. Se estiver testando localmente ou em múltiplos domínios, defina no .env: SECURE_URL=*