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.

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.

SESSION

Server-side\nper-user state

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.

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