Filtering a library query to the current user helps return the right records. It does not establish permission for every operation on a record identifier.
In Snipr, the server functions check ownership separately for reads, creation, mutation, and relationships.
Let identity supply the owner#
Snippet creation reads the authenticated identity and assigns its subject to the record. Accepting an arbitrary owner from the client would give the caller control over a field that defines access.
Retrieval uses a user index, and favorite retrieval uses a user-and-favorite index. These align the query with the library's common access patterns.
Load the record before mutating it#
Update and deletion resolve the snippet identifier to its stored record, then compare the owner to the authenticated subject. A syntactically valid identifier can still refer to another person's record.
The check therefore belongs in the server operation that performs the change. Hiding an edit button is useful interface behavior, but does not decide whether the caller may edit the stored snippet.
Validate both ends of a relationship#
Adding a snippet to a folder requires two ownership checks. The snippet must belong to the caller, and the folder must belong to the caller.
Checking the folder alone would leave the referenced snippet unchecked. Checking the snippet alone would leave the destination unchecked. The operation changes a relationship, so both records matter.
Review new features against the same questions#
An index makes retrieval efficient for its intended pattern. Authorization comes from identity and record checks. Keeping those responsibilities explicit makes future features easier to review.
If Snipr later introduces shared folders, the relationship rules will need a new permission model. The current checks demonstrate personal-library ownership; they do not establish a sharing model that has not been implemented.