Logged-In User Context

Use session-backed identity in Wappler pages and actions so the app can show the current user safely and consistently.

Introduction

Demo Projects HQ uses current-user data in two different ways, and that distinction answers a common source of confusion. For every page using layouts.main, app/config/routes.json applies route-level restrict plus exec: "api/auth/current_user" on the layout. During route handling, that action runs before EJS renders, so the navbar and sidebar partials receive current_user in locals without any explicit page-level dmx-serverconnect call. On views/user_edit.ejs, the page also loads /api/auth/current_user again through sc_current_user_api so App Connect can make client-side comparisons after render. This is the right baseline: one provider-backed identity source can feed both server-rendered EJS and runtime page guardrails without turning editable form data into authority.

Server-rendered locals

`layouts.main` runs `api/auth/current_user` before render, which is why EJS partials can read `current_user` directly from `locals`.

Client-side reuse

`views/user_edit.ejs` also loads `sc_current_user_api` so App Connect can compare the signed-in account against the edited record after the page is already running.

Use the shared security provider as the source of current-user truth.

Show current-user context where it clarifies the interface or protects a workflow.

Keep the signed-in account separate from whatever record the page is editing.

Let server-side security stay authoritative even when the page uses current-user data for guardrails.

The admin user edit page is a concrete current-user example

This page is useful because it contains both current-user patterns at once. The shared layout already had current_user in EJS locals before render, so the shell could show role-aware UI immediately. Then views/user_edit.ejs loads sc_current_user_api separately so the running page can compare the signed-in account against the record being edited. Seeing both layers together makes the request lifecycle much easier to understand.

Properties panel shows where the guardrail lives

With the delete form selected, the Properties panel is the clearest place to understand the page rule. Demo Projects HQ is not hiding this decision in a custom script. The visibility logic is attached directly to the element whose availability depends on the signed-in account.

Current-user context prevents deleting your own account here

The delete form is shown only when the edited user id differs from sc_current_user_api.data.current_user.id. That is a concrete example of current-user context doing useful work: the page compares the record in the editor with the signed-in account and removes a destructive action when both identities are the same.

important: This is a UI guardrail, not the only layer of protection. The secure action still needs to enforce who may delete which account.

Keep the signed-in user separate from the record being edited

The role field belongs to the user record currently open in the editor, not to the signed-in account returned by current_user. Demo Projects HQ keeps those identities separate on purpose. That separation is what prevents form-bound data from being mistaken for session authority.

Switch to the dashboard to review the shared application shell

Current-user data is not only for guardrails on detail pages. Now switch to the dashboard so you can inspect how the shared shell presents the signed-in account to the user.

The shell surfaces display name, email, and role from the same session context

On the dashboard layout, the navbar and sidebar partials read current_user directly from EJS locals. In Demo Projects HQ that works because the main layout route runs api/auth/current_user before template rendering, so display name, email, and role are already attached server-side when those partials render. That is different from adding a dmx-serverconnect component to a page after load, but it still comes from the same provider-backed session context that protected routes and server actions trust.

Next steps

Demo Projects HQ shows current-user context in two useful ways: it drives visible orientation in the shared shell, and it adds concrete page-level guardrails where the signed-in account must be compared against another record. Both flows stay anchored to the same shared security provider, which is what keeps the behavior trustworthy.