diff --git a/docs/docs/handlers-and-http/sessions.md b/docs/docs/handlers-and-http/sessions.md index 625ca0d8..e28be327 100644 --- a/docs/docs/handlers-and-http/sessions.md +++ b/docs/docs/handlers-and-http/sessions.md @@ -25,7 +25,11 @@ How the session ID cookie is generated can also be tweaked by leveraging the fol How session data is actually persisted can be defined by configuring the right session store backend, which can be done through the use of the [`sessions.store`](../development/reference/settings.md#store) setting. -By default, sessions are stored within a single cookie (`:cookie` session store). Cookies have a 4K size limit, which is usually sufficient in order to persist things like a user ID and flash messages. `:cookie` is the only store that is built in the Marten web framework presently. +By default, sessions are encrypted and stored within a single cookie (`:cookie` session store). Cookies have a 4K size limit, which is usually sufficient in order to persist things like a user ID and flash messages. `:cookie` is the only store that is built in the Marten web framework presently. + +:::info +The `cookie` store leverages a [`Marten::Core::Encryptor`](pathname:///api/dev/Marten/Core/Encryptor.html) encryptor object in order to encrypt and sign session data. This means that session data is encrypted with an **aes-256-cbc** cipher and signed with HMAC signatures that use the **SHA256** hash algorithm. +::: Other session stores can be installed as separate shards. For example, the [`marten-db-session`](https://github.com/martenframework/marten-db-session) shard can be leveraged to persist session data in the database while the [`marten-redis-session`](https://github.com/martenframework/marten-redis-session) shard can be used for persisting session data using Redis. diff --git a/docs/versioned_docs/version-0.4/handlers-and-http/sessions.md b/docs/versioned_docs/version-0.4/handlers-and-http/sessions.md index 65c21e3c..2e76714b 100644 --- a/docs/versioned_docs/version-0.4/handlers-and-http/sessions.md +++ b/docs/versioned_docs/version-0.4/handlers-and-http/sessions.md @@ -25,7 +25,11 @@ How the session ID cookie is generated can also be tweaked by leveraging the fol How session data is actually persisted can be defined by configuring the right session store backend, which can be done through the use of the [`sessions.store`](../development/reference/settings.md#store) setting. -By default, sessions are stored within a single cookie (`:cookie` session store). Cookies have a 4K size limit, which is usually sufficient in order to persist things like a user ID and flash messages. `:cookie` is the only store that is built in the Marten web framework presently. +By default, sessions are encrypted and stored within a single cookie (`:cookie` session store). Cookies have a 4K size limit, which is usually sufficient in order to persist things like a user ID and flash messages. `:cookie` is the only store that is built in the Marten web framework presently. + +:::info +The `cookie` store leverages a [`Marten::Core::Encryptor`](pathname:///api/0.4/Marten/Core/Encryptor.html) encryptor object in order to encrypt and sign session data. This means that session data is encrypted with an **aes-256-cbc** cipher and signed with HMAC signatures that use the **SHA256** hash algorithm. +::: Other session stores can be installed as separate shards. For example, the [`marten-db-session`](https://github.com/martenframework/marten-db-session) shard can be leveraged to persist session data in the database while the [`marten-redis-session`](https://github.com/martenframework/marten-redis-session) shard can be used for persisting session data using Redis.