Admingen checks access on the server. The application identifies the user, then checks whether the operation is permitted. Hidden menu items or form fields do not protect data from direct API requests.
Configuring access in Generator UI
- In Content, open entity settings and Access.
- Under Entity CRUD access, enable required operations and configure each external mode. Admin and external access are separate.
- Add visibility conditions under External READ access, for example
status equal published. For virtual entities, configure source, selectedbelongsToand collection blocks separately. - Inspect Generated routes, then Generate → Preview changes → Generate.
- Sign in to the running admin. Create the first superadmin using terminal instructions; afterwards manage accounts in the interface.
Accounts and roles
After first sign-in, permitted account operations include creation, password reset, blocking/unblocking and session revocation. Authentication accounts are separate from ordinary entities: deleting an entity record does not delete an account.
superadmin manages the admin application within its capabilities. admin performs enabled entity operations. External user access is configured separately. A menu module groups entities; it is not a role or inherited permission set.
Sessions
On sign-in, the server issues a short-lived access token and session-refresh cookie. The token stays in page memory, not persistent browser storage. After reload, the client restores the session through refresh.
The cookie has HttpOnly. Refresh and logout check CSRF and request origin. Logout, revocation, password changes and blocking affect further access. Even a correctly signed token cannot authorize an already-revoked session.
Integration routes
| Method and path | Action |
|---|---|
POST /api/auth/v1/login |
Sign in with credentials. |
POST /api/auth/v1/refresh |
Refresh through the cookie with CSRF checks; empty body. |
POST /api/auth/v1/logout |
End the session; empty body. |
GET /api/auth/v1/me |
Get the current user. |
POST /api/auth/v1/password/change |
Change your own password. |
GET/POST /api/admin/v1/_auth/accounts |
List or create accounts with the superadmin role. |
POST /api/admin/v1/_auth/accounts/{accountID}/password-reset |
Reset an account password. |
POST .../{accountID}/block / unblock |
Block or unblock an account. |
POST .../{accountID}/sessions/revoke |
Revoke account sessions. |
JSON request sizes are bounded. Sign-in and password changes validate body shape and reject arbitrary data. Passwords and tokens must not appear in URLs, public data or logs.
Sign-in lost after reload
Check admin/API addresses, allowed origins and cookies. localhost and 127.0.0.1 are different names. Use a coordinated HTTPS server layout. Arbitrary UI/API placement on unrelated sites is unsupported for refresh cookies.
Do not disable CSRF for a 403. Check the expected Origin and actual loaded configuration. Proxy/PostgreSQL settings are in runtime security.
Reading particular records
External mode determines who can call a route. readRule determines which records external list/get returns. Explicitly configure status = published in Access to return published records only. Merely including published in enum options imposes no restriction.
Virtual entities and their collections have their own rules; source-entity rules are not inherited. These rules do not change admin reads or writes. See virtual entities.
Switches and conditions are in Content: access. Record rules and environment settings solve different problems and are both needed independently.