Skip to content
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

Reject request in on_connect middleware #840

Closed
t123yh opened this issue Aug 3, 2022 · 2 comments
Closed

Reject request in on_connect middleware #840

t123yh opened this issue Aug 3, 2022 · 2 comments

Comments

@t123yh
Copy link

t123yh commented Aug 3, 2022

I'm implementing a websocket jsonrpc server. I'm planning to do some sort of authentication using the on_connect middleware. In case of authentication failure, the request should be rejected, no further websocket connection should be opened. Can we add some sort of "return code" to the on_connect middleware function to decide whether the request should be accepted?

@jsdw
Copy link
Collaborator

jsdw commented Aug 3, 2022

The HttpMiddleware/WsMiddleware should probably be named something different (see #843); they are unable to modify the request/response and really just exist to allow for basic logging and metric gathering.

We will soon be supporting the tower::Service trait on our Http Server soon (see #841); this may be a better place to add such authentication (assuming you would be happy running the HTTP and not WS server, at least. In the future I'd like to see more "proper" middleware support like this added (probably based on this Service trait), but they aren't a high priority for us at the mo.

My suggestion at the moment would be to add any authentication stuff separately in front of your jsonrpsee server, if the http trait wouldn't be sufficient. It should be possible for you to capture and do whatever you like within coming http/ws requests before they hit Jsonrpsee, albeit more effort than plugging in osme middleware to do the same :)

@jsdw
Copy link
Collaborator

jsdw commented Aug 17, 2022

I'm going to close this for now; it's not something we have any plans to implement (but we have clarified the naming of that middleware and landed "proper" http middleware.

@jsdw jsdw closed this as completed Aug 17, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants