Web Notepad evolved: now it has optional authentication, ownership, and access control

Rogerio Rodrigues — Sat, 25 Apr 2026 22:57:02 +0000

In my first post, I introduced Web Notepad as a simple online notepad: open, write, and share by link, with no mandatory signup.

That original idea is still the same: low friction.

But the main feedback I kept getting was straightforward:

“I want to share by link, but I don’t always want anyone with the link to be able to change or delete my content.”

That feedback shaped the next evolution of the product.

The goal became:

⚡ keep anonymous usage fast;
🔐 add optional authentication;
👤 allow a note to have an owner;
🛡️ provide real control over reading and editing;
🧭 keep the frontend experience simple and the API predictable.

Live product: https://webnotepad.com.br/

First post: https://www.tabnews.com.br/rbrodrigues/criei-o-web-notepad-um-bloco-de-notas-online-publico-sem-login-e-ja-em-producao

✨ What changed in practice

1) 🔑 Optional Google sign-in

The system now supports Google authentication without turning the product into a heavy suite or forcing registration for everything.

That means:

users who just want to open a note and type can still do it quickly;
users who want more control can sign in and gain access to ownership and governance features.

2) 👤 Note ownership

A note can now be linked to a user.

This moves the product away from the pure “whoever has the link can do everything” model toward a more controlled model, while preserving the original simplicity.

In practice, this opened the door to clearer authorization rules and owner-specific actions.

3) 🧩 Four access modes

The system now supports four access modes:

PUBLIC_EDIT
AUTHENTICATED_EDIT
PUBLIC_READ
PRIVATE_OWNER

This was an important change because the previous behavior was too binary.

Now I can represent real-world scenarios such as:

🌍 a public collaborative note;
👀 a note visible to anyone with the link, but editable only by the owner;
🔒 a note restricted to the owner;
✅ a note accessible only to authenticated users who have the link.

I also kept compatibility with the previous model so that the evolution wouldn’t break the existing foundation.

4) 🔓 The “unclaim” flow

One improvement I found especially useful was the ability to unlink ownership.

Now the owner can simply give up ownership of a note without deleting it.

In practice, this means:

the note no longer has an owner;
it returns to public editable mode;
it disappears from that user’s “My notes” list.

This solves a very real product case:

“I don’t want to manage this note anymore — I just want to make it public again.”

🛠️ What changed in the backend

Most of the backend evolution focused on a few major points:

🟣 Google authentication behind a feature flag;
🟣 ownership through claim;
🟣 the unclaim flow;
🟣 an authorization model with four access modes;
🟣 clearer error semantics via messageKey;
🟣 stricter rules for sensitive actions, such as deletion being owner-only.

Some of the endpoints involved in this evolution:

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

The API errors also became more explicit, with semantic keys such as:

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

This made frontend integration easier because it reduced fragile text parsing and improved user-facing feedback.

🎨 What changed in the frontend

On the frontend, the goal was to make this new layer of control visible and understandable without cluttering the interface.

The main improvements were:

🟢 Google login with a more stable session;
🟢 a dashboard segmented by scope;
🟢 ownership made visible inside the editor;
🟢 per-card actions in the dashboard;
🟢 a complete unlink/unclaim flow;
🟢 a multilingual user manual inside the application.

In practice, the frontend gained much better note management without losing the fast editing experience.

🧠 Technical decisions that helped the most

🚩 Feature flags first

This allowed me to activate authentication and ownership more safely in production, without forcing a big-bang rollout.

🔄 Backward compatibility

Mapping the old behavior into the new model avoided unnecessary breakage.

🧾 Clear semantic errors

Having a dedicated messageKey for each scenario simplified the frontend and improved the user experience.

🛡️ Security in the backend, UX in the frontend

Authorization lives in the backend.
The frontend improves usability, visibility, and feedback — but it is not responsible for enforcing security rules.

❤️ What I wanted to preserve

Even with authentication, ownership, and access modes, I wanted to preserve the pillars of the first version:

⚡ fast creation;
🔗 link-based usage;
💾 autosave;
🔄 cross-client updates;
🧼 a clean API;
🪶 a product that stays easy to understand.

In other words:

more governance without losing simplicity.

🔭 What I’m evaluating next

These are the areas I’m looking at now:

explicit user invitations;
richer auditing for sensitive actions;
anti-abuse improvements without killing simplicity;
deeper production observability.

✅ Closing thought

The main lesson so far has been this:

It is possible to keep the experience simple while evolving the system for more realistic collaboration and access-control scenarios.

Web Notepad is still fast for people who just want to open a note and type.

But now it also serves real use cases where people want to share without giving up governance.

If there’s interest, I can make a follow-up post focused only on the implementation details: layers, contracts, feature-flag rollout, and the trade-offs I found along the way.

DEV Community: Rogerio Rodrigues