# Harmony – Controle Financeiro
## Plano de Correção de Segurança + Melhorias

*Elaborado por Aurora (Sinapse) — 30/07/2026. Auditoria somente-leitura; nenhum dado foi alterado.*

---

## Situação atual (resumo)

O sistema funciona e é bonito, mas está **aberto na internet**. Dois problemas críticos:

1. **Senhas em texto puro dentro do código do site** — qualquer um que veja o código-fonte pega todos os logins, inclusive o do admin.
2. **Banco de dados (Firebase) sem proteção** — dá pra ler e gravar tudo sem fazer login, indo direto no banco pelo endereço que está no próprio site (confirmado em teste de leitura).

Na prática, os dados financeiros da Harmony estão públicos. As correções abaixo são em ordem de urgência.

---

# PARA O CLAUDE CODE (DA HARMONY) EXECUTAR — leia primeiro

Este documento é um **roteiro executável**. Quem aplica tudo é o **Claude Code de vocês**, rodando na máquina/ambiente com acesso às contas. Você (Claude Code) executa as Fases 0 a 3 de ponta a ponta, seguindo as Partes 1 e 2.

**O que pedir ao dono antes de começar** (sem isso não dá):
1. **Token de API do Cloudflare** com permissão **Workers Scripts: Edit** (Cloudflare → Meu Perfil → Tokens de API → Create Token). Account ID: `2a214ba8ee42fc5febdfad1cd53356db`
2. **Chave de conta de serviço do Firebase** (`.json`) do projeto `harmony-controle` (Firebase Console → Configurações do projeto → Contas de serviço → Gerar nova chave privada) — **ou** rodar `firebase login` na conta Google do projeto.
3. **Confirmação explícita** para prosseguir: isto altera um sistema **financeiro no ar**.

**Ferramentas:** Cloudflare → `wrangler` (ou `curl`, Parte 2-A). Firebase → `firebase-tools`, `gcloud`, e o Admin SDK (Node/Python) para criar usuários.

**Como executar** (resumo; detalhe nas Partes 1 e 2):
1. Baixe o código atual do Worker (backup) pela API do Cloudflare.
2. No código do Worker: **remova** o array de usuários com senha (`password:'...'`); **troque** a conferência de senha por `signInWithEmailAndPassword` (Firebase Auth); **adicione** os cabeçalhos de segurança (Fase 3).
3. Crie os usuários no Firebase Authentication (senhas fortes).
4. Publique as **regras** do Firestore que exigem login (Fase 1.4) **e** o Worker corrigido — de preferência no mesmo momento, pro app não ficar quebrado no meio.
5. Restrinja a chave de API ao domínio (Fase 0.1).
6. **Teste (obrigatório):** login de cada papel funciona; o banco **recusa** acesso sem login (leitura sem token → `PERMISSION_DENIED`); o código servido **não** tem mais senha.
7. Se algo falhar, reverta pelo histórico de deploy do Cloudflare (e restaure o backup do passo 1).
8. Ao final, peça ao dono para **rotacionar** todas as chaves usadas.

**Regra de ouro:** backup antes, teste depois, e nunca deixe o banco aberto entre um passo e outro.

---

# PARTE 1 — Passo a passo da correção

## Fase 0 — Emergência (fazer hoje)

**0.1 — Restringir a chave do Firebase ao site oficial**
- Acesse **Google Cloud Console → APIs e Serviços → Credenciais**.
- Abra a chave de API do projeto `harmony-controle`.
- Em **Restrições de aplicativo**, escolha **Referenciadores HTTP** e adicione:
  - `controleharmony.harmonysantos2024.workers.dev/*`
- Salve. Isso impede que a chave seja usada de outro site.

**0.2 — Fechar o banco (regra provisória)**
> ⚠️ Isso vai "travar" o app até a Fase 1 (login de verdade) estar pronta. Se preferir, pule direto pra Fase 1 e aplique a regra final lá. Não deixe o banco aberto de um dia pro outro.

- Firebase Console → **Firestore Database → Regras** → cole e publique:
```
rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read, write: if false;   // fechado até ter login
    }
  }
}
```

---

## Fase 1 — Login de verdade (Firebase Authentication)

Hoje o login é "de mentira": a senha é conferida no navegador, contra uma lista escrita no código. Vamos usar o **Firebase Authentication** (o próprio Google guarda as senhas, criptografadas).

**1.1 — Ativar o método de login**
- Firebase Console → **Authentication → Sign-in method** → ativar **E-mail/Senha**.

**1.2 — Criar os usuários lá**
- Em **Authentication → Users → Add user**, cadastre cada pessoa (admin e vendedoras) com **senha forte** (mínimo 12 caracteres, sem ser nome+123).

**1.3 — Ajustar o código do site**
- Adicionar o SDK de auth (junto dos outros scripts do Firebase):
```html
<script src="https://www.gstatic.com/firebasejs/10.12.0/firebase-auth-compat.js"></script>
```
- **Remover do código a lista de usuários com senha** (o trecho `password:'...'`).
- Trocar a conferência de senha pelo login real:
```js
const auth = firebase.auth();
async function login(email, senha) {
  const cred = await auth.signInWithEmailAndPassword(email, senha);
  return cred.user;           // se falhar, cai no catch e mostra "login inválido"
}
```
- Guardar o **papel** (admin/vendedora/viewer) numa coleção protegida `usuarios/{uid}` (só o admin escreve), não no código.

**1.4 — Regra final do Firestore (exige login)**
- Firestore → Regras → publique:
```
rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read, write: if request.auth != null;   // só quem fez login
    }
  }
}
```

**1.5 — Trocar todas as senhas** (as antigas vazaram; nenhuma serve mais).

---

## Fase 2 — Permissão por papel (quem pode o quê)

Hoje "admin/vendedora/viewer" é checado só na tela — dá pra burlar. Vamos deixar o banco decidir.

- Guardar o papel em `usuarios/{uid}` (campo `role`).
- Regra que lê o papel (exemplo: só admin apaga; vendedora só mexe nas próprias vendas):
```
function papel() {
  return get(/databases/$(database)/documents/usuarios/$(request.auth.uid)).data.role;
}
match /vendas/{id} {
  allow read: if request.auth != null;
  allow create, update: if request.auth != null;
  allow delete: if papel() == 'admin';
}
```
*(a estrutura exata depende de como os dados forem organizados — ver Ideia 1 na Parte 2.)*

---

## Fase 3 — Endurecer o resto (no Worker do Cloudflare)

O site não manda nenhum cabeçalho de segurança. Dá pra adicionar direto no Worker, envolvendo a resposta:
```js
const resp = await servirPagina(request);   // resposta atual
const h = new Headers(resp.headers);
h.set('Content-Security-Policy', "default-src 'self' https://*.gstatic.com https://*.googleapis.com https://cdnjs.cloudflare.com; img-src 'self' data:;");
h.set('X-Frame-Options', 'DENY');            // evita clonar num iframe
h.set('Strict-Transport-Security', 'max-age=31536000');  // força HTTPS
h.set('X-Content-Type-Options', 'nosniff');
return new Response(resp.body, { status: resp.status, headers: h });
```

---

## Checklist rápido

- [ ] Restringir a chave do Firebase ao domínio (Fase 0.1)
- [ ] Ativar Firebase Authentication e criar usuários (Fase 1.1/1.2)
- [ ] Tirar as senhas do código + usar login real (Fase 1.3)
- [ ] Publicar as regras do Firestore que exigem login (Fase 1.4)
- [ ] Trocar todas as senhas (Fase 1.5)
- [ ] Permissão por papel (Fase 2)
- [ ] Cabeçalhos de segurança no Worker (Fase 3)
- [ ] Rotacionar as chaves que foram compartilhadas (Cloudflare API token, R2, Firebase)

---

# PARTE 2 — Aplicar as correções automaticamente (via API / Claude Code)

O Claude Code (ou a Aurora) roda num servidor com internet e pode aplicar boa parte disso sozinho por linha de comando. Ponto importante: as mudanças ficam em **dois lugares diferentes, com credenciais diferentes**.

| O quê | Onde | Credencial | O token que você mandou serve? |
|---|---|---|---|
| Publicar o código corrigido do site | Cloudflare (Worker) | Token do Cloudflare | ✅ Sim (se tiver permissão de Edit) |
| Fechar o banco (regras) | Firebase/Google | Chave de conta de serviço | ❌ Não — precisa gerar |
| Criar login de verdade + usuários | Firebase/Google | Chave de conta de serviço | ❌ Não |
| Restringir a chave de API | Google Cloud | Chave de conta de serviço | ❌ Não |

> Traduzindo: **o token do Cloudflare só publica o código do site.** Os dois problemas críticos (banco aberto + login) são no **Firebase**, e pra automatizar isso o Claude Code precisa de uma **chave de conta de serviço do Google** (explicado em B).

## A) Cloudflare — publicar o código corrigido (usa o token atual)

Requisito: o token precisa da permissão **Workers Scripts → Edit** (o atual consegue ler; confirmar/adicionar em *Cloudflare → Meu Perfil → Tokens de API*).

```bash
export CF_TOKEN="<token>"
export ACCT="2a214ba8ee42fc5febdfad1cd53356db"

# 1) Backup da versao atual (o Cloudflare tambem guarda historico de deploy)
curl -s -H "Authorization: Bearer $CF_TOKEN" \
  "https://api.cloudflare.com/client/v4/accounts/$ACCT/workers/scripts/controleharmony" \
  -o backup_worker_$(date +%F).js

# 2) Publicar a versao corrigida (worker.js = codigo novo, sem senhas + com login + cabecalhos)
curl -X PUT -H "Authorization: Bearer $CF_TOKEN" \
  -H "Content-Type: application/javascript" \
  --data-binary @worker.js \
  "https://api.cloudflare.com/client/v4/accounts/$ACCT/workers/scripts/controleharmony"
```
Alternativa oficial (mais simples): **`wrangler deploy`** apontando pro projeto.

## B) Firebase — fechar banco, login e chave (precisa de credencial do Google)

Essas mudanças são no Google/Firebase — o token do Cloudflare **não** alcança. Pra automatizar, gere uma chave de conta de serviço:

- Firebase Console → **Configurações do projeto → Contas de serviço → Gerar nova chave privada** → baixa um `.json`.

Com esse arquivo, o Claude Code aplica:
```bash
export GOOGLE_APPLICATION_CREDENTIALS="/caminho/harmony-sa.json"

# 1) Regras do Firestore (arquivo firestore.rules com o conteudo da Fase 1.4)
firebase deploy --only firestore:rules --project harmony-controle

# 2) Criar os usuarios com senha forte (Admin SDK — script Node/Python)
#    Ex.: admin.auth().createUser({ email, password }) para cada pessoa

# 3) Restringir a chave de API ao dominio do site (Google Cloud)
gcloud alpha services api-keys update <KEY_ID> \
  --allowed-referrers="controleharmony.harmonysantos2024.workers.dev/*" \
  --project harmony-controle
```

**Sem essa chave de serviço**, as partes do Firebase são feitas **na mão no console** (é exatamente o passo a passo da Parte 1 — funciona igual, só não é automático).

## Ordem segura de execução (recomendada)

1. Preparar o `worker.js` corrigido (sem senhas, com login Firebase e cabeçalhos) e revisar.
2. Criar os usuários no Firebase Authentication.
3. Publicar as **regras** que exigem login (Fase 1.4).
4. **No mesmo momento**, publicar o Worker corrigido (para o app não quebrar entre um passo e outro).
5. Testar login de cada papel + confirmar que o banco recusa acesso sem login.
6. Restringir a chave de API e **rotacionar** todas as chaves usadas.

> ⚠️ Publicar o Worker **substitui o app no ar** — fazer com backup antes (passo A.1) e testar logo depois. O Cloudflare permite reverter pelo histórico de deploy.

---

# PARTE 3 — Novas ideias de implementação

*(depois que o básico de segurança estiver de pé)*

**1. Guardar cada venda como um registro próprio (fim do risco de perder dados).**
Hoje o sistema salva "o pacote inteiro" de uma vez, e quem salva por último apaga o que a outra vendedora acabou de fazer. O certo é cada venda/cliente/agendamento ser um documento separado no banco — aí duas pessoas podem trabalhar ao mesmo tempo sem uma apagar a outra. Resolve a maior fragilidade do sistema.

**2. Versão mobile de verdade.** Vendedora usa celular; hoje o app quase não se adapta à tela. Um ajuste de responsividade (tabelas viram cartões no celular, botões maiores) muda a experiência do dia a dia.

**3. App instalável (PWA) com funcionamento offline.** Dá pra "instalar" o sistema no celular como um aplicativo e ele continuar funcionando sem internet, sincronizando quando voltar. Ótimo pra quem vende na rua.

**4. Metas e comissão automática por vendedora.** Cada vendedora com sua meta do mês, barra de progresso, e a comissão calculada sozinha a partir das vendas. Motiva o time e tira conta manual.

**5. Fechamento de caixa e relatório do dia/mês.** Um botão que fecha o dia, mostra entradas, formas de pagamento e manda o resumo (PDF ou WhatsApp) pra dona.

**6. Backup automático diário.** Uma cópia dos dados todo dia, guardada separada — se alguém apagar algo por engano, dá pra recuperar.

**7. Avisos no WhatsApp.** Confirmação de agendamento pro cliente, lembrete um dia antes, e resumo diário de vendas pra Harmony. Reduz falta e dá visão em tempo real.

**8. Histórico de alterações de verdade (no servidor).** Registrar quem criou/editou/apagou cada venda, guardado no banco (não no navegador, onde some e dá pra adulterar). Importante num sistema financeiro.

**9. Dashboard com indicadores.** Ticket médio, vendas por vendedora, produtos/serviços mais vendidos, comparativo com o mês anterior — pra decisão, não só lançamento.

**10. Otimização de carregamento.** Compactar o arquivo (hoje 713 KB sem compactar) e separar os dados do código; o site abre bem mais rápido, principalmente no celular com internet fraca.

---

*Recomendação: as Ideias 1 e 2 (registros próprios + mobile) são as de maior impacto no dia a dia; as demais entram conforme a prioridade da Harmony. A Sinapse pode assumir a correção de segurança e a evolução, se fizer sentido.*