Skip to content

docs(README): clarify use of getSessionIdentifier #115

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
psibean merged 1 commit into from
May 15, 2025
Merged

docs(README): clarify use of getSessionIdentifier #115

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 3 additions & 3 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -170,7 +170,7 @@ When initialising <code>doubleCsrf</code>, you have a lot of options available f
```js
const doubleCsrfUtilities = doubleCsrf({
getSecret: () => "Secret", // A function that optionally takes the request and returns a secret
getSessionIdentifier: (req) => req.session.id, // A function that returns the session identifier for the request
getSessionIdentifier: (req) => req.session.id, // A function that returns the unique identifier for the request
cookieName: "__Host-psifi.x-csrf-token", // The name of the cookie to be used, recommend using Host prefix.
cookieOptions: {
sameSite = "strict",
Expand Down Expand Up @@ -208,9 +208,9 @@ This should return a secret key or an array of secret keys to be used for hmac g

<p><b>Required</b></p>

<p>This function should return the session identifier for the incoming request. This is used as part of the <em>message</em> used to generate the hmac, it ensures that generated CSRF tokens can only be used by the sessions that originally requested them.</p>
<p>This function should return the unique identifier for the incoming request, typically this would be the session id or JWT. The unique identifier should be something that is different each time it is constructed for the same user. The return value is used as part of the <em>message</em> to generate the hmac, it ensures that generated CSRF tokens can only work for the matching identifier that originally requested them.</p>

<p>If you are rotating your sessions (which you should be), you will need to ensure a new CSRF token is generated at the same time. This should typically be done when a session has some sort of authorisation elevation (e.g. signed in, signed out, sudo).</p>
<p>If you are rotating your sessions (which you should be), you will need to ensure a new CSRF token is generated at the same time. This should typically be done when a session has some sort of authorisation elevation (e.g. signed in, signed out, sudo). If you're using a JWT and you aren't using it as a cookie, you likely don't need CSRF protection, check the <a href="./FAQ.md#do-i-need-csrf-protection>">Do I need CSRF protection?"</a> section of the FAQ.</p>

<h3>cookieName</h3>

Expand Down