Skip to content

Websocket & middlewares #999

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
1 task done
horvbalint opened this issue Mar 30, 2025 · 1 comment
Open
1 task done

Websocket & middlewares #999

horvbalint opened this issue Mar 30, 2025 · 1 comment
Labels
enhancement New feature or request

Comments

@horvbalint
Copy link

Describe the feature

Last week I wanted to add websocket to an existing nitro app, but ran into some unexpected behaviours. I think fixing/improving these would be beneficial for everyone.

I have two main parts of my api /public/* and /protected/*. There is a middleware registered, that is authenticating the user on every /protected/* route and also adds the user object to event.context.
My plan was simple, create a /protected/ws.ts route, that is using definedEventHandler. This way (in my plan) I wouldn't need to duplicate the authentication logic and everything should work nicely. This is sadly not the case.

  • middlewares do not run for websocket routes. I think this sohuld be treated as a bug and kinda serious imo.
  • there is no way to access the event, or event.context in defineWebsocketHandler's upgrade callback. This means that even if middlewares did run, the result could not reach the websocket handler.

Additional information

  • Would you be willing to help implement this feature?
@horvbalint horvbalint added the enhancement New feature or request label Mar 30, 2025
@horvbalint
Copy link
Author

I think this would also fix #715

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant