Skip to content

Pass CSRF token using Sec-WebSocket-Protocol header #418

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.

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

Open
ptaoussanis opened this issue Feb 23, 2023 · 0 comments
Open

Pass CSRF token using Sec-WebSocket-Protocol header #418

ptaoussanis opened this issue Feb 23, 2023 · 0 comments

Comments

@ptaoussanis
Copy link
Member

For more context: #137 (comment)

iarenaza added a commit to iarenaza/sente that referenced this issue Apr 2, 2025
The proposed change tries to respect other values in the
Sec-WebSocket-Protocol header, that the caller may have set in the
`headers` option when calling `make-channel-socket-client!`

[Re: taoensso#418]
iarenaza added a commit to iarenaza/sente that referenced this issue Apr 2, 2025
The proposed change tries to respect other values in the
Sec-WebSocket-Protocol header, that the caller may have set in the
`headers` option when calling `make-channel-socket-client!`

[Re: taoensso#418]
iarenaza added a commit to iarenaza/sente that referenced this issue Apr 5, 2025
The proposed change tries to respect other values in the
Sec-WebSocket-Protocol header, that the caller may have set in the
`headers` option when calling `make-channel-socket-client!`

[Re: taoensso#418]
ptaoussanis pushed a commit that referenced this issue Apr 7, 2025
…@iarenaza)

Before this commit:
  WebSocket client conveys CSRF token to server via `:csrf-token` query param.

After this commit:
  WebSocket client conveys CSRF token to server via `Sec-WebSocket-Protocol` header.

Motivation:
  Moving the token from query param to a header helps reduce the likelihood of
  accidental leaking (e.g. via logging).

  While the `Sec-WebSocket-Protocol` header isn't specifically intended for conveying
  metadata like a CSRF token, the consensus seems to be that this is anyway a practical
  choice without major downsides or obviously better alternatives.

As implemented the change tries to respect other values in the `Sec-WebSocket-Protocol`
header that may have been set when calling `make-channel-socket-client!`.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant