Skip to main content
When someone logs in to your app, you want the app to remember them on every page after that. That memory is called a session: the server stores a few facts (for example, the username), and the browser holds a small cookie with a session id that points to those facts. Under Swoole, many requests share one server process, so sessions must be kept in per-request objects — never in shared variables. Winter Boot gives you three pieces for this: SessionManager opens and saves sessions, RequestSession holds one request’s session data, and SessionOptions describes the cookie.

Logging in

Ask the manager for the session, store what you need, and save it before returning. Everything is ready to autowire — no setup code is needed:
AuthController.php
commit() saves the data and puts the session id into a cookie on the response. Always call it before returning — anything you set() without commit() is thrown away when the request ends.

Reading the session on the next request

Open the session the same way. If the browser sent back a valid session cookie, you get the stored data; otherwise you get a fresh, empty session:

Logging out

This deletes the stored data and tells the browser to drop the cookie. SessionOptions is a plain object — you create one per login flow with new, right where you use it. Different flows need different cookies: an admin login might last 15 minutes on HTTPS only, while a regular user login lasts all day. Give each flow its own cookie name and they stay independent, even in the same browser:
Pass the right one to open() and commit(). Both flows can share the same store — the cookie name keeps their sessions apart. If you only ever need one kind of login, one SessionOptions is enough.

Knowing who is logged in

Two fields travel with every session: username and session type. Set them at login:
They are loaded back automatically on every later request, so code that only updates other data never erases them. The username is written once at login: later saves that carry no name keep the stored one, so it cannot be wiped by accident — only a new name replaces it. The session type is a number your app defines (for example, 1 for admins) — 0 simply means “no type set”.

Where sessions are kept

Out of the box, sessions are stored in files on the server — fine for getting started or a single server. For several servers, or sessions that must survive a restart, use a database or Redis instead by declaring one store bean (it must return \SessionHandlerInterface):

Database sessions

Create the table once:
Then expose the store:
SessionConfig.php
created_at records when the session was first saved; updated_at refreshes on every save. Old, expired sessions can be cleaned up automatically.

Redis sessions

The winter-data-redis module offers dev\winterframework\data\redis\session\RedisSessionStore, which keeps each session as a hash under keyPrefix + sessionId and lets Redis expire old sessions by itself. Like the database store, it persists username and session type with the same write-once rule:
SessionConfig.php

The session API