Executando verificação de segurança...
1
rbrodrigues
5 min de leitura ·

Web Notepad evoluiu: agora tem autenticação opcional, ownership e controle de acesso

No meu primeiro post, eu apresentei o Web Notepad como um bloco de notas online simples: abrir, escrever e compartilhar por link, sem cadastro obrigatório.

A proposta continua a mesma: baixa fricção.
Mas o principal feedback que apareceu foi bem direto:

“Quero compartilhar por link, mas nem sempre quero que qualquer pessoa apague ou altere meu conteúdo.”

Foi esse ponto que guiou a próxima evolução do projeto.

A ideia, então, passou a ser esta:

  • ⚡ manter o uso anônimo rápido;
  • 🔐 adicionar autenticação opcional;
  • 👤 permitir que um bloco tenha dono;
  • 🛡️ dar controle real de leitura e edição;
  • 🧭 continuar com uma experiência simples no frontend e previsível na API.

Projeto em produção: https://webnotepad.com.br/
Post inicial: https://www.tabnews.com.br/rbrodrigues/criei-o-web-notepad-um-bloco-de-notas-online-publico-sem-login-e-ja-em-producao

texto

✨ O que mudou na prática

1) 🔑 Login opcional com Google

O sistema agora suporta autenticação com Google, sem transformar o produto em uma suíte pesada ou obrigar cadastro para tudo.

Ou seja:

  • quem só quer abrir um bloco e escrever continua conseguindo fazer isso rápido;
  • quem quer mais controle agora pode se autenticar e passar a ter recursos de ownership e governança.

2) 👤 Ownership de bloco

Agora um bloco pode ser vinculado a um usuário.

Isso permite sair do modelo puro de “quem tem o link faz tudo” para um modelo com mais controle, mantendo a simplicidade da proposta original.

Na prática, isso abriu espaço para regras mais claras de autorização e ações específicas do dono.

3) 🧩 Quatro modos de acesso

O sistema passou a suportar quatro modos de acesso:

  • PUBLIC_EDIT
  • AUTHENTICATED_EDIT
  • PUBLIC_READ
  • PRIVATE_OWNER

Essa mudança foi importante porque antes o comportamento era muito binário.
Agora dá para representar cenários reais de uso, como:

  • 🌍 bloco público e colaborativo;
  • 👀 bloco visível para qualquer pessoa com link, mas editável só pelo dono;
  • 🔒 bloco restrito ao dono;
  • ✅ bloco acessível apenas para usuários autenticados com link.

Também mantive compatibilidade com o modelo anterior, para a evolução não quebrar a base já existente.

texto

4) 🔓 Fluxo de “desvincular” bloco

Uma melhoria que achei especialmente útil foi o fluxo de desvincular ownership.

Agora o dono pode simplesmente “abrir mão” do bloco sem precisar excluí-lo.

Na prática, isso significa:

  • o bloco deixa de ter dono;
  • volta para modo público editável;
  • sai da lista de blocos daquele usuário.

Esse fluxo resolve um caso muito real de produto:

“Não quero mais administrar esse bloco, só quero deixá-lo público de novo.”

texto

🛠️ O que entrou no backend

No backend, a evolução ficou concentrada em alguns pontos principais:

  • 🟣 autenticação com Google por feature flag;
  • 🟣 ownership com claim;
  • 🟣 fluxo de unclaim;
  • 🟣 modelo de autorização com quatro modos de acesso;
  • 🟣 regras de erro mais explícitas via messageKey;
  • 🟣 endurecimento de regras sensíveis, como exclusão apenas pelo dono.

Alguns endpoints envolvidos nessa evolução:

  • POST /api/auth/google
  • GET /api/auth/me
  • POST /api/auth/logout
  • PATCH /api/users/me
  • POST /api/pads/{slug}/claim
  • POST /api/pads/{slug}/unclaim

Além disso, os erros passaram a ter chaves semânticas mais claras, como:

  • auth.required
  • pad.owner.onlyEdit
  • pad.owner.onlyDelete
  • pad.owner.alreadyClaimed
  • pad.owner.notClaimed
  • pad.accessMode.invalid

Isso ajudou bastante a integração com o frontend, porque reduziu dependência de parsing textual frágil.

🎨 O que entrou no frontend

No frontend, a preocupação foi fazer essa nova camada de controle aparecer de forma clara para o usuário, sem poluir a interface.

As principais melhorias foram:

  • 🟢 login Google com sessão mais estável;
  • 🟢 dashboard segmentado por escopo;
  • 🟢 ownership visível no editor;
  • 🟢 ações por card no painel;
  • 🟢 fluxo completo de desvincular bloco;
  • 🟢 manual do usuário multi-idioma dentro da própria aplicação.

Na prática, o frontend ganhou uma visão melhor de gestão, sem perder a experiência rápida do editor.

texto

🧠 Decisões técnicas que mais ajudaram

🚩 Feature flags primeiro

Permitiu ativar autenticação e ownership com mais segurança em produção, sem forçar uma mudança brusca.

🔄 Compatibilidade com legado

Mapear o comportamento antigo para o novo modelo evitou ruptura desnecessária.

🧾 Erros com semântica clara

Ter messageKey específica por cenário simplificou o frontend e melhorou o feedback para o usuário.

🛡️ Segurança no backend, UX no frontend

A autorização está no backend.
O frontend melhora usabilidade, visibilidade e feedback, mas não carrega a responsabilidade da regra de segurança.

❤️ O que eu quis preservar

Mesmo com autenticação, ownership e modos de acesso, eu quis preservar os pilares da versão inicial:

  • ⚡ criação rápida;
  • 🔗 uso por link;
  • 💾 autosave;
  • 🔄 atualização entre clientes;
  • 🧼 API limpa;
  • 🪶 produto simples de entender.

Em outras palavras:

mais governança sem perder a proposta de simplicidade.

🔭 Próximos passos que estou avaliando

Os pontos que estou olhando agora são:

  • convite explícito por usuário;
  • auditoria mais rica para ações sensíveis;
  • melhorias anti-abuso sem matar simplicidade;
  • mais observabilidade em produção.

✅ Fechamento

A principal lição até aqui foi esta:

dá para manter a experiência simples e, ao mesmo tempo, evoluir o sistema para cenários mais reais de colaboração e controle.

O Web Notepad continua rápido para quem quer só abrir e escrever.
Mas agora já consegue atender melhor casos em que o usuário quer compartilhar sem abrir mão de governança.

Se fizer sentido, no próximo post eu posso trazer os recortes mais técnicos dessa implementação: camadas, contratos, rollout com feature flag e trade-offs que apareceram no caminho.

Carregando publicação patrocinada...