-
-
Notifications
You must be signed in to change notification settings - Fork 593
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
Allow server and web admin APIs to listen on separate port to websocket #44
Comments
Hello! About Web UI. At moment you can start Centrifugo without UI at all just omitting Could you configure access on location level? For example something like this in Nginx:
? About API. There is option Hope I understood issue correctly. |
Thanks for the reply! I realise you can disable web but like I said we would need a way to bypass login like you said so we could run it on separate instance.
Could do that but in our case we will probably have an AWS ELB right in front of centrifugo doing TCP load balancing so it can't know anything about http request path or routing... Adding whole extra proxy layer just to secure it is possible but it would be much nicer just to not have the api exposed at all (or only on a separate listening port we can control separately). If you are unsure it's useful to anyone else, I can implement in a fork but it would be great to not be running custom version! I think my prefered option would be:
The simpler option is:
|
I think it's better to do as much as possible before forking to custom version. This can happen eventually but at moment all these things seems reasonable. I think a combination of your points must be done here:
I am considering to add some logic into |
Sounds good. If you don't post here I might have a go at this soon but probably not for this week at least so if you want to that will be awesome :) |
Started implementing this in separate branch (https://github.com/centrifugal/centrifugo/tree/separate_ports), changed some points above:
|
Commented on commits - looks awesome thanks. I'll give the branch a try really soon - hopefully next day or two. |
Will be released with v1.3.0 |
Hi
I love the web UI - useful tool. But we certainly couldn't expose it like it is now with just static password in production.
What we could do instead is run our production public instances with it turned off, and then run a separate instance connected to same redis with web on and only expose this over our internal VPN. Or alternatively put it behind our admin proxy that is hooked into our robust user authentication.
But for the second approach to work, we'd need to then make it have no password in config so that users don't need to auth twice (and remember some global made up password).
An alternative I think would be generally useful would be to be able to configure the web interface to be on, to NOT need password, but to listen on a separate port to the public websocket/sockjs server.
That would allow us to run the web UI on same nodes as production but to ensure they are not publically accessible - put them behind our authenticating proxy and/or only expose them over VPN.
While we are at it, I'd like to propose the same for the server API. I realise that the HMAC offers some security for it, but in our case we never want public access so it would be necessary to just lock it down completely.
One option would be disable the server API on the public nodes and have separate instance again only accessible internally but that would require changes. Again it would be neatly solved if you could optionally configure the API to listen on a separate port to the sockjs/websocket endpoint such that we could use same instances but keep access to those totally private at network level rather than rely on HMAC and obscurity.
tl;dr I'm going to end up modifying centrifugo to do either of the following. If you have input on which if any you like the sound of for core project I'll put my effort into that so I can contribute it back.
Thanks for the great project by the way - I started writing something extremely similar for our large scale site after being disappointed at all the open source alternatives I tried, and my design was about as close as can possibly be imagined to the details of centrifugo. I'm very happy you already built it for us :).
The text was updated successfully, but these errors were encountered: