Securing Fliplet data sources
Securing Fliplet data sources
Protect app data with server-evaluated access rules, then test the allowed and denied operations as real app users. Rules control access; browser checks and successful Studio administrative requests do not prove authorization.
Configure a policy
- Open App Data in Fliplet Studio, select the data source and open Access Rules.
- Define the actors, operations and fields that need protection. Start with an explicit empty rules array (
[]) for a source that should deny app access until configured. Missing or null rules retain legacy unrestricted access. - Choose a security example with explicit scope and adapt its data shape and login-source binding. Save the rules, then read back the configuration.
- Test both allowed and denied operations with Enforce security enabled in preview. Confirm persisted results using a fresh read.
A minimal public read-only policy is:
[
{ "type": ["select"], "allow": "all" }
]
Use this only for data intended for anonymous readers. It grants no insert, update or delete operation. The public lookup example pairs this rule with sample rows and SDK calls.
Choose the right guide
| Task | Guide |
|---|---|
| Understand rule order, identity, requirements and endpoint differences | Security rule reference |
| Explore public, shared, owner-filtered reads, profile or role/state examples | Security examples |
| Prove allowed and denied app behavior | Authenticated preview testing |
| Connect, query or write through JavaScript | Fliplet.DataSources reference |
| Configure authentication or hooks | App authentication, Session API and Data source hooks |
Check the policy’s limits
Rules grant access in order. A failed rule falls through for writes as well as reads, so a later broad grant can defeat an earlier restriction.
Object conditions on updates check the stored row, while string requirements check submitted key presence. A condition that checks stored Owner or Status does not prevent a permitted write from changing those fields. Single-record writes honor exclude, but bulk/commit writes do not provide the same field protection. Custom scripts receive a copied input; assigning audit fields to that copy does not reliably persist them.
For immutable ownership or approval transitions, keep app-user writes unavailable until an implemented trusted write path has been verified to check both stored and proposed values on every supported endpoint. See role and state limits before choosing a workflow policy.
Existing section links
These destinations retain links to the previous sections of this guide.
Replacement: owner-scoped single-record profiles. This example demonstrates enabled-owner edits and single-write filtering, not the former role/protected-field policy.
Replacement: owner-filtered read illustration. This illustrates individual owner reads, not department/manager access or complete source privacy.
Data requirements and query validation