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

Socket connection from browser to custom microservice through webapp-starter #11

Open
akshayeshenoi opened this issue Aug 3, 2017 · 5 comments

Comments

@akshayeshenoi
Copy link

Hi!
Is it currently possible to reverse-proxy WebSocket connections initiated by the browser to a custom microservice? The lack of it requires the front-end to connect to the microservice directly which entails authentication woes.

@gstroup
Copy link
Contributor

gstroup commented Aug 3, 2017

No, currently the webapp-starter does not support proxying websocket connections. It's a good idea, and something we've considered. For now, you could look at the predix-toolkit code for an example of proxying web socket connections.
https://github.com/PredixDev/predix-tool-kit/blob/master/server/security-app.js

Also, this npm package is very popular, and supports web socket proxying:
https://github.com/nodejitsu/node-http-proxy

@akshayeshenoi
Copy link
Author

Would you be willing to accept a PR?

@gstroup
Copy link
Contributor

gstroup commented Aug 4, 2017

Yes, I think a PR would be useful. How are you planning to implement it?

@akshayeshenoi
Copy link
Author

akshayeshenoi commented Aug 13, 2017

Kind of like how it's implemented in the predix-toolkit example code you shared.

  • A websocket server will be instantiated on the webapp-starter.
  • Clients will hit a certain endpoint to connect to the websocket on another microservice.
  • A new ws connection to the microservice will be established by the webapp-starter (acting as a client), and a new socketID will be generated for it which will be returned to the client. The new socket created will be stored in-memory against the ID.
  • The client will then connect to the websocket we instantiated before and send the ID within the body of the message. The webapp-starter will use that ID to fetch the socket and forward the message.

All communication will depend upon this socketID. Sounds good?

@gstroup
Copy link
Contributor

gstroup commented Aug 14, 2017

Sounds good. Let's try to keep most of this logic in a separate file in the /server directory. Thanks for the initiative.

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