Logout Button and Session Exit

Build a predictable logout flow in Wappler so sessions end cleanly and protected areas become inaccessible immediately.

Introduction

This tour treats logout as part of the full security lifecycle, not as a small UI detail. In Wappler, a good logout flow ends the session, removes access to protected routes, and sends the user somewhere that still makes sense after identity is gone.

Logout is a server-side security event

A logout button is only trustworthy when it clears the authenticated session on the server side. Hiding a menu item or redirecting the page without ending the session is only cosmetic and leaves protected actions exposed.

End the session

The underlying auth state must be cleared, not just the UI.

Return to a safe route

Send the user to a page that does not require the previous session.

Invalidate protected context

Protected pages and actions should immediately stop working.

Treat logout as the inverse of login

Clear the real auth state first

Make the post-logout route explicit

Design the post-logout handoff deliberately

Users should understand where they land after logout and why. In most apps that means a login page, a marketing page, or a neutral dashboard entry point. The important part is consistency between the visible redirect and the server-side session state.

Pick one default post-logout destination

Keep protected routes behind restriction rules

Test refresh behavior after logout

Common logout patterns

A stable logout flow usually combines a server action, a visible trigger, and a predictable redirect.

The visible logout trigger can live in a navbar, menu, or account area, but the action behind it should remain the same. Keep the UI trigger simple and let the action own session termination and redirect behavior.

Use one canonical logout action

Reuse it from every logout entry point

Keep the UI trigger thin

Pattern: verify that protected routes really close

After logout, revisit a protected route or action path. If the app still loads protected data, the route or server action is not enforcing the security provider strongly enough.

important: The logout flow is only complete when previously protected pages and APIs become inaccessible without signing in again.

Retest protected pages after logout

Retest secure actions after logout

Check both layout-level and action-level protection

Logout sits between login and page restriction in the overall auth lifecycle. It works best when the provider, login page, and restricted routes already follow one shared model.

Wrap-up

Continue into the broader security flow from here.

Next steps

Choose the next security topic to continue with.