chore(deps): update dependency csrf-csrf to v4

[renovate]

This PR contains the following updates:

Package	Change	Age	Adoption	Passing	Confidence
csrf-csrf	3.2.2 -> 4.0.2

---

Release Notes

Psifi-Solutions/csrf-csrf (csrf-csrf)

v4.0.2

Compare Source

Bug Fixes

• broken type exports (8967de6)

v4.0.1

Compare Source

Bug Fixes

• correctly skip CSRF token validation when validateOnReuse is false (bcaf1c3)

v4.0.0

Compare Source

⚠ BREAKING CHANGES

This list may not be an exhaustive list of breaking changes, for more information consult the version 3 -> 4 upgrade guide and the updated configuration documentation in the README.

• Token generation now uses createHmac, the format has changed significantly, see the CSRF token format section of the upgrade guide.
• getSessionIdentifier is now required and must return a unique identifier per-request (and per-session) - this is an essential part of CSRF token security
• getTokenFromRequest renamed to getCsrfTokenFromRequest
• generateToken renamed to generateCsrfToken
• overwrite and validateOnReuse parameters for generateCsrfToken have been merged into a single object parameter which also accepts cookieOptions: generateCsrfToken(req, res, options);
• Default value for validateOnReuse is now false
• Default value for cookieOptions.sameSite is now strict
• cookieOptions.signed is no longer available, CSRF tokens are inherently signed, this is redundant
• delimiter option removed, csrfTokenDelimiter and messageDelimiter are now used for the respective purpose
• signed option in cookieOptions config option removed (redundant), csrf tokens generated by csrf-csrf are inherently signed
• size config option now sets the size of the message used to construct the hmac, now defaults to 32 instead of 64, this is combined with the return value of getSessionIdentifier to construct the hmac payload
• Type CsrfTokenCookieOverrides renamed to CsrfTokenCookieOptions
• Type CsrfTokenCreator renamed to CsrfTokenGenerator
• Type doubleCsrfProtection renamed to DoubleCsrfProtection
• Type RequestMethod renamed to CsrfRequestMethod
• Type CsrfIgnoredMethods renamed to CsrfIgnoredRequestMethods

Features

• change default value of sameSite to 'strict' (ba5973e)
• change validateOnReuse to false by default (5fc62a9)
• expose per token cookie settings (#​60) (456b317)
• types: add CsrfTokenGeneratorRequestUtil type (72fd659)
• use hmac to generate csrf tokens (e4c5ec3)

3.2.2 (2025-04-24)

Bug Fixes

• types: fix incorrect type for Request#csrfToken (cf3dfe2), closes #​95

3.2.1 (2025-04-20)

No changes, just re-published the botched 3.2.0

---

Configuration

📅 Schedule: Branch creation - "before 3am" (UTC), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.

[github-actions]

Folder/File	Previous size	New size	Difference
/upload/TriliumNextNotes-Server-1799-merge-linux-x64.tar.xz		69MB	+69MB (+100.00%)
TOTAL			+69MB

[renovate]

Edited/Blocked Notification

Renovate will not automatically rebase this PR, because it does not recognize the last commit author and assumes somebody else may have edited the PR.

You can manually request rebase by checking the rebase/retry box above.

⚠️ Warning: custom changes will be lost.

[pano9000]

setting overwrite: true will cause issues to people that use the Server build and open up the interface on separate browser tabs (not Trilium internal tabs, but actual browser tabs)

it is explained in the packages README as well:

If overwrite is set to true, the function will generate a new token and cookie each time it is invoked. This behavior can potentially lead to certain complications, particularly when multiple tabs are being used to interact with your web application. In such scenarios, the creation of new cookies with every call to the function can disrupt the proper functioning of your web app across different tabs, as the changes might not be synchronised effectively (you would need to write your own synchronisation logic).

I assume you went this way because of the following?
https://github.com/Psifi-Solutions/csrf-csrf/blob/HEAD/UPGRADING.md#zero-downtime-upgrade-zdu

Deleting the existing cookie should be enough to fix that issue though (in theory -> I didn't test locally yet though).

edit:
btw: I was experiencing the exact same issue, back when I introduced csrf-csrf :-)

edit 2:
Alternative idea to fix this:
if we rename the cookie from "_csrf" to anything else, that should also "workaround" the issue.
I was anyways thinking if we maybe wanted to rename it to include "trilium" in the name anyways

[eliandoran]

@pano9000 , I think changing the name of the cookie is the way to go.

[pano9000]

thanks :-)