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 already shows current-user context in places where it changes real behavior, so this does not need to stay a conceptual tour. The admin user edit page loads the signed-in account through /api/auth/current_user and uses that trusted identity to decide what the page may show or hide. This is the right baseline: current-user data comes from the shared security provider, then the page uses it for orientation and guardrails without turning editable form data into authority.

Trusted identity source

The page asks the security-backed current_user action for the signed-in account instead of guessing from client state.

Real UI consequence

That current-user context changes what the page allows, including whether the delete form should be shown.

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 not just editing another user record. It also loads the signed-in account separately so the page can compare the editor against the record being edited. That distinction is what makes current-user context valuable in real applications.

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 account area in the shared navbar reads from current_user again to present the signed-in identity clearly. Display name, email, and role all come from the same provider-backed session context that protected routes and server actions already trust. This is the healthy pattern: one identity source, reused for both orientation and enforcement-aware UI.

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.