DEV Community

Auth By Example
Auth By Example

Posted on

A share link should stop working when the person who made it loses access

Most apps that let you share a record by link store the link as a random token plus the record ID. Someone opens the link, the server finds the token and shows the record. The app saves who created the link, but nothing checks that person again.

This breaks when the creator's own access changes. A contractor shares a project doc with a client, then the contract ends and an admin removes them from the workspace. The link they made still opens the doc. The same thing happens when someone moves to another team and loses a folder, or when a doc is moved into a restricted space after the link was made.

Treat the link as acting for its creator. When someone opens it, check that the creator can still read the record right now, and that the link's level (view, comment or edit) is no higher than what the creator has today. If either check fails, return the same error you'd return for an unknown token, so whoever holds the link can't tell the record still exists.

When you deactivate a user, list the links they created and show them to the admin doing it. Some are fine to keep, like a public pricing sheet, and the admin can hand those to someone who still has access.

To test it, create a link as a regular user, remove that user from the workspace, then open the link in a private window. If the record loads, your links don't check their creator.

Top comments (2)

Collapse
 
launchgatecheck profile image
Launch Gate •

I'd extend the removal test with remove-then-readd: create an edit link, remove the creator, then restore their workspace membership. Should that old token become live again automatically? Checking current access alone can allow that resurrection unless revocation is recorded separately. A permission downgrade and an admin handoff are useful companion cases: the link shouldn't silently regain edit rights later, and handing ownership to another person shouldn't widen its original scope. Making that lifecycle explicit would help distinguish a temporarily unusable link from a revoked one.

Collapse
 
authbyexample1 profile image
Auth By Example •

No, it shouldn't. Record the revocation on the link itself (a revoked_at timestamp or a token version bump) when the creator loses access, and check it on every read. Re-adding the creator then doesn't bring the old token back, so they'd have to make a new link.