Users and rights

Five tables hold users, groups and rights:

A right is referenced from a page (userRightUuid, editRightUuid) and from a block (userRightNeeded).

WebUser is an entity

Not an object, not a session bag: an entity. Treat it as one. It has attributes, and reaching for a property that does not exist returns undefined rather than raising an error.

Admin screens use a right, not a hard-coded code

Access to /bweb/* goes through an ADMIN_<SLUG> right. Older code tested code = "DEV"; that is not the model any more.

Two possible failures, both misleading:

• a 404 caused by a null publish on an admin URL: it looks like a missing route, it is an unpublished page;
• a 403 on every event of an admin screen until the right is granted: it looks like a broken button.

Display rights are not access control

userRightNeeded decides whether a block is rendered. On its own, it does not protect data: hidden still ships the content to the browser. For anything that must not reach an unauthorised visitor, use notLoaded or a page-level right. And remember the POST is checked again regardless of what was displayed (see Security).

A user whose code is filled can disappear from lists

A vt_FirstRequest written as code = '' filters out every user that has a code, silently and everywhere at once: list, filters, export, merge. If users are missing from every screen, look at the first request before looking at rights.

Sessions

The login session is lost on a 4D restart, which is why the dev panel vanishes and /bweb/login has to be replayed. A persistence cookie is only re-created when there really is a connected user; otherwise logging out would never stick.

See also

• Pages and routing: userRightUuid / editRightUuid on the page
• Security: the check that runs on every POST