update

Author: amirhhashemi

src/routes/solid-start/advanced/session.mdx

@@ -6,40 +6,35 @@ Sessions allow web applications to maintain state between user requests.
 Since HTTP is stateless, each request is treated independently.
 Sessions address this by allowing the server to recognize multiple requests from the same user, which is helpful for tracking authentication and preferences.
 
-
 ## How sessions work
 
 A session typically involves:
 
 1. **Session creation**: When tracking is needed (e.g., upon login or first visit), the server creates a session.
-   This involves:
-   - Generating a unique **session ID**.
-   - Storing the session data _encrypted and signed_ within a cookie.
+   This involves generating a unique **session ID** and storing the session data, _encrypted and signed_, within a cookie.
 2. **Session cookie transmission**: The server sends a `Set-Cookie` HTTP header.
    This instructs the browser to store the session cookie.
 3. **Subsequent requests**: The browser automatically includes the session cookie in the `Cookie` HTTP header for requests to the server.
 4. **Session retrieval and data access**: For each request, the server:
-   - Checks for the session cookie.
-   - Retrieves session data from the cookie.
-   - Decrypts and verifies the signature of the session data.
-   - Application code can access and use this data.
-5. **Session expiration and destruction**: Sessions typically expire after a time or upon user logout.
-   Destruction involves instructing the browser to delete the session cookie (e.g., setting an expired `Set-Cookie`).
+   1. Checks for the session cookie.
+   2. Retrieves the session data if a cookie is present.
+   3. Decrypts and verifies the signature of the session data for the application to access and use this data.
+5. **Session expiration and destruction**: Sessions typically expire after a period of time or upon user sign-out and the data is removed.
+   This is done by setting a `Max-Age` attribute on the cookie or by sending a `Set-Cookie` HTTP header with an expired date.
 
-Most of these steps are automatically managed by [session helpers](#session-helpers).
+Most of these steps are automatically managed by the [session helpers](#session-helpers).
 
 ### Database sessions
 
 For larger applications or when more robust session management is required, SolidStart also supports storing session data in a database.
 This approach is similar to the cookie-based approach, but with some key differences:
 
-1. A session ID is generated.
-2. The session data is stored in the database, associated with the session ID.
-3. Only the session ID is stored in the cookie.
-4. The session data is retrieved from the database using the session ID.
-5. Upon expiration, in addition to the session cookie, the database record containing the session data is also removed.
+- The session data is stored in the database, associated with the session ID.
+- Only the session ID is stored in the cookie, not the session data.
+- The session data is retrieved from the database using the session ID, instead of being retrieved directly from the cookie.
+- Upon expiration, in addition to the session cookie, the database record containing the session data is also removed.
 
-Note that managing interactions with the database is not directly supported by SolidStart; you will need to implement this yourself.
+SolidStart does not automatically handle interactions with a database; you need to implement this yourself.
 
 ## Session helpers
 
@@ -89,7 +84,7 @@ In this example, the `useThemeSession` server function creates a session that st
 
 `useSession` requires a strong password for encrypting and signing the session cookie.
 This password must be at least 32 characters long and should be kept highly secure.
-It is strongly recommended to store this password in an environment variable, as shown in the example above, rather than hardcoding it in your source code.
+It is strongly recommended to store this password in a [private environment variable](/configuration/environment-variables#private-environment-variables), as shown in the example above, rather than hardcoding it in your source code.
 
 A password can be generated using the following command:
 
@@ -100,9 +95,9 @@ openssl rand -base64 32
 `useSession` adds a `Set-Cookie` HTTP header to the current server response.
 By default, the cookie is named `h3`, but can be customized with the `name` option, as shown in the example above.
 
-## Getting session data
+## Getting the session data
 
-The `useSession` helper provides access to the session data through the `data` property.
+The `useSession` helper provides access to the session data from the current request with the `data` property.
 
 ```ts title="src/lib/session.ts"
 export async function getThemeSession() {
@@ -113,28 +108,26 @@ export async function getThemeSession() {
 }
 ```
 
-## Updating session data
+## Updating the session data
 
-The `useSession` helper provides an `update` method to modify session data.
+The `useSession` helper provides the `update` method to update the session data from the current request.
 
 ```ts title="src/lib/session.ts"
 export async function updateThemeSession(data: SessionData) {
 	"use server";
 	const session = await useThemeSession();
-
 	await session.update(data);
 }
 ```
 
-## Clearing a session
+## Clearing the session data
 
-The `useSession` helper provides a `clear` method to destory the session.
+The `useSession` helper provides the `clear` method to clear the session data from the current request.
 
 ```ts title="src/lib/session.ts"
 export async function clearThemeSession() {
 	"use server";
 	const session = await useThemeSession();
-
 	await session.clear();
 }
 ```