66 releases (28 breaking)

0.66.2 Mar 6, 2024
0.65.2 Feb 2, 2024
0.63.1 Dec 21, 2023
0.59.0 Nov 30, 2023
0.37.6 Nov 29, 2022

#1165 in HTTP server

Download history 117/week @ 2023-11-27 125/week @ 2023-12-04 71/week @ 2023-12-11 42/week @ 2023-12-18 12/week @ 2023-12-25 37/week @ 2024-01-01 61/week @ 2024-01-08 75/week @ 2024-01-15 27/week @ 2024-01-22 15/week @ 2024-01-29 10/week @ 2024-02-05 107/week @ 2024-02-12 89/week @ 2024-02-19 402/week @ 2024-02-26 1247/week @ 2024-03-04 140/week @ 2024-03-11

1,887 downloads per month
Used in 3 crates

MIT/Apache

650KB
15K SLoC

salvo-session

Session management for Salvo.

This is offical crate, so you can enable it in Cargo.toml like this:

salvo = { version = "*", features=["session"] }

Documentation & Resources


lib.rs:

Salvo session support

Salvo session middleware is built on top of async-session.

An example: session-login

Sessions allows salvo to securely attach data to a browser session allowing for retrieval and modification of this data within salvo on subsequent visits. Session data is generally only retained for the duration of a browser session.

Stores

It is highly recommended that salvo applications use an external-datastore-backed session storage. For a list of currently available session stores, see the documentation for async-session.

Security

Although each session store may have different security implications, the general approach of salvo's session system is as follows: On each request, salvo checks the cookie configurable as cookie_name on the handler.

A cryptographically random cookie value is generated. A cookie is set on the outbound response and signed with an HKDF key derived from the secret provided on creation of the SessionHandler. The configurable session store uses a SHA256 digest of the cookie value and stores the session along with a potential expiry.

The hkdf derived signing key is used to verify the cookie value's signature. If it verifies, it is then passed to the session store to retrieve a Session. For most session stores, this will involve taking a SHA256 digest of the cookie value and retrieving a serialized Session from an external datastore based on that digest.

Expiry

In addition to setting an expiry on the session cookie, salvo sessions include the same expiry in their serialization format. If an adversary were able to tamper with the expiry of a cookie, salvo sessions would still check the expiry on the contained session before using it

If anything goes wrong with the above process

If there are any failures in the above session retrieval process, a new empty session is generated for the request, which proceeds through the application as normal.

Stale/expired session cleanup

Any session store other than the cookie store will accumulate stale sessions. Although the salvo session handler ensures that they will not be used as valid sessions, For most session stores, it is the salvo application's responsibility to call cleanup on the session store if it requires it.

Read more: https://salvo.rs

Dependencies

~23–38MB
~666K SLoC