SESSION
Server-side\nper-user state
Server Connect Actions: Session & Cookie inputs
Understand session vs cookie data, how they relate to login/auth, and how to use them as inputs in actions.
Session & Cookie inputs: logged-in context
This tour builds a clear mental model for “stateful” inputs.
SESSION is server-side per-user data (who they are, what they can do). COOKIE is a small client-stored value sent with requests.
You’ll learn where to define these inputs and how to bind them safely in step Properties.
COOKIE
Client-stored\nrequest header
Security
Don’t trust\nraw client data
Session is where authenticated identity usually lives.
Cookies are for small values; never trust them blindly.
Define inputs under Inputs so they’re typed/validated.
Opening the sample action…
Loading the example action into the Server Connect editor.
If this is the first time, it can take a moment while the editor initializes.
The Server Connect editor is ready
The sample action is now open in the dedicated editor, so the next steps can focus on the tree selection and the Properties panel it drives.
Tree selection drives the Properties panel
This sample action already includes SESSION and COOKIE-related steps in the workflow tree. Keep the tree selection in mind, because that is what populates the Properties panel on the right.
SESSION vs COOKIE (mental model)
Both SESSION and COOKIE feel like “inputs”, but they behave very differently.
SESSION lives on the server (the browser typically only sends a session identifier). COOKIE lives in the browser and is sent as a request header.
Practical rule: trust SESSION more than COOKIE. Cookies can be missing, modified, or copied between browsers.
SESSION = server-side per-user state (identity/role).
COOKIE = client-side storage (preferences, small tokens).
Never store secrets or permissions “only in a cookie”.
$_SESSION: bind the current user
SESSION inputs are typically how your action knows who is calling it.
Example: $_SESSION.user_id often comes from your login/auth flow.
Once you have a user id, you can safely load the user record, apply permissions, and scope database queries.
Use session role for permissions
A common pattern is storing a simple role/permission in the session (or deriving it after login).
Here we compute is_admin from $_SESSION.role.
Tip: permissions should ultimately be enforced on the server (DB rules, authorization steps), not only in the UI.
$_COOKIE: bind user preferences
Cookies are good for small preference-like values.
Example: $_COOKIE.theme (dark/light) can control UI theming or return different CSS.
Important: treat cookies as untrusted input. Validate allowed values, and keep permissions in SESSION or the database.
How to add Session/Cookie inputs
To add these inputs:
- Select Inputs
- Add a new input with a name (like
user_id,role,theme) - Choose a Data Type and add rules (required, allowed values, etc.)
Then you can bind them anywhere using $_SESSION.* and $_COOKIE.*.
Wrap-up
You now know what session and cookie inputs are, and when to use each.
Pick a next tour based on what you want to build next.
Quick recap
SESSION is trusted server-side per-user state (identity/role). COOKIE is client-provided values (prefs/tokens) that must be validated.
Use inputs + rules to keep the rest of your workflow predictable.
Use SESSION for identity/authorization context.
Use COOKIES mainly for preferences and small client state.
Validate cookie values; enforce permissions server-side.
Next steps
Continue with other input sources, or go back to the editor hub.
URL inputs (GET + Route)
POST body inputs
Back to the editor hub