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

Authenticate/Restrict client cmdline option #47

Closed
mightypenguin opened this issue Jun 7, 2012 · 2 comments
Closed

Authenticate/Restrict client cmdline option #47

mightypenguin opened this issue Jun 7, 2012 · 2 comments
Labels
feature New feature or request patchwelcome

Comments

@mightypenguin
Copy link

For my application I handle authentication at the server where websockify runs, not on the VNC server itself.
The VNC server runs on a hidden non-public network.

Websockify is spawned in response to user connection requests and ideally I would like to add randomly generated password that noVNC would pass to authenticate that it is the intended client.

Failing that, a simpler approach would be to have a cmdline option to pass websockify the client's IP address to expect connections from.
I already use the run-once and connection timeout options but if someone was hammering my server they might be able to hijack a session before the client can connect. VNC's builtin password system is weak security IMO. My authentication system needs to be multi-user which is handled just fine upstream of websockify except for the small window of time between when it is spawned and noVNC connects to it.

Does this sound workable?
I'd assume the patch for checking the IP address is simple, but I'm curious if this would be broadly usable by others.

@kanaka
Copy link
Member

kanaka commented Jun 8, 2012

@mightypenguin, yep, that's a good idea. We used a similar mechanism with IP restriction at my former employer, part of the external system that launched websockify also installed a temporary iptables rules for that specific source IP.

See this pull request: #16 for a generic external authentication mechanism and my comments on it (the original pull author never got back to implementing my suggestions unfortunately).

Basically it would like like this: websockify would take an option for an external validation script which would be called for every new client connection. That script would be invoked with environment variables that contain all the connection header information. The script would then return 0 if the connection is allowed, or something else (perhaps mapping codes to websocket close codes) if the connection is denied. This would keep the basic websockify uncluttered with various authentication mechanisms (which will likely vary significantly based on what framework websockify is being integrated into) and give it a generic mechanism for authenticating connections. For example, one of the most basic authentication scripts (which should be included as an example) should be one which verifies the origin/host information (CORS) rather than the current everything is allowed situation.

@DirectXMan12
Copy link
Member

See #172 for an implementation of this

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

No branches or pull requests

3 participants