Regression caused by a29946e9. We were no longer detecting a cleanly
closed proxy socket. This is not a WebSocket, but an ordinary one,
so we should be checking for "" rather that None.
* Incorporates #190 without breaking compatibility towards old Python versions.
* A new plugin allows authenticating clients by the "common name" defined in their certificate.
* Added manual for certificate-based client authentication, including hints to which Python versions allow client certificate authentication.
* Adjusted test to work with new ssl.create_default_context.
With the --inetd parameter, websockify doesn't require the source_addr and
source_port paramters and it expects that stdin is already opened and listening
socket.
This way websockify can be used with (x)inetd or as a systemd socket-activated
service.
This commit adds support to unix sockets in the token plugin, thus it is
possible to have a token files like:
token: unix_socket:/path/to/socket_file
A single websockify instance will be able to handle multiple sockets.
Signed-off-by: Jose Ricardo Ziviani <jose@ziviani.net>
This commit reworks auth plugins slightly to enable
support for HTTP authentication. By raising an
AuthenticationError, auth plugins can now return
HTTP responses to the upgrade request (such as 401).
Related to kanaka/noVNC#522
Previously, we just passed the values of '--*-plugin' and
'--*-source' directly to `LibProxyServer` and `WebSocketProxy`,
which handled turning that into an instance of the plugin class.
Now, that's done in main, and the classes receive an instance
directly.
Auth plugins provide a generic interface for authenticating requests.
The plugin name is specified using the '--auth-plugin' option, and
may either be the name of a class from `websockify.auth_plugins`,
or a fully qualified python path to the auth plugin class (see below).
An optional plugin parameter can be specified using the '--auth-source'
option (a value of `None` will be used if no '--auth-source' option is
specified).
Auth plugins should inherit from `websockify.auth_plugins.BasePlugin`,
and should implement the `authenticate(headers, target_host, target_port)`
method. The value of the '--auth-source' option is available as
`self.source`.
One plugin is currently included: `ExpectOrigin`. The `ExpectOrigin`
plugin checks that the 'Origin' header is an expected value. The list
of acceptable origins is passed using the plugin source, as a
space-separated list.
Previously, if no `target_cfg` flag was used, the `target_cfg` option
would not get removed from the opts dict, causing an error when it got
passed through to `WebSocketProxy`. Now we always remove it.
Fixes#168.
Token plugins provide a generic interface for transforming a token
into a `(host, port)` tuple.
The plugin name is specified using the '--token-plugin' option,
and may either be the name of a class from `websockify.token_plugins`,
or a fully qualified python path to the token plugin class (see below).
An optional plugin parameter can be specified using the '--token-source'
option (a value of `None` will be used if no '--token-source' option is
passed).
Token plugins should inherit from `websockify.token_plugins.BasePlugin`,
and should implement the `lookup(token)` method. The value of the
'--token-source' option is available as `self.source`.
Several plugins are included by default. The `ReadOnlyTokenFile`
and `TokenFile` plugins implement functionality from '--target-config'
(with the former only reading the file(s) once, and the latter reading
them every time). The 'BaseTokenAPI' plugin fetches the value from
an API, returning the result of `process_result(response_object)`.
By default, `process_result` simply returns the text of the response,
but may be overriden. The `JSONTokenAPI` does just this, returning
the 'host' and 'port' values from the response JSON object.
The old '--target-config' option is now deprecated, and maps to the
`TokenFile` plugin under the hood.
Also-Authored-By: James Portman (@james-portman)
Closes#157
* commit '477dce6cf86d61b20a394f3cbf3170e60d199658':
websocket: use python logging module
websocket: fix exception statement introduced by comment 903e3f06ee557
Adapted to new standard SocketServer RequestHandler design. For
example, this means that self.i_am_client is not needed.
WebSocketServer is a library module, as such, it cannot assume it can
write output to process stdout.
Python logging module is designed in order to allow subscribers to
handle the output out of modules. It is simple and generic mechanism to
separate between data producer and data handling.
Python logging API also has the nature of log level, so the verbose
parameter can probably be obsoleted in favor of logging level. And of
course the logging API has built in support for exception tracebacks, no
need for manual format.
Per upstream request a wrapper is created around python logging to
enable shorter statements and optional replacement.
Add --traffic parameter for traffic specific debug, this is required as
it uses direct unformatted stdout output.
Signed-off-by: Alon Bar-Lev <alon.barlev@gmail.com>
The WebSocketProxy class is usable for creating derived applications
with different logic, especially for the target validation.
Current code assumes that target is a path while in other implementation
it can be object that is loaded at initialization.
This change moves the conversion to absolute path into main function, so
that the WebSocketProxy class will not make that assumption.
Signed-off-by: Alon Bar-Lev <alon.barlev@gmail.com>
refactoring. Basically, we are dividing WebSocketServer into two
classes: One request handler following the SocketServer Requesthandler
API, and one optional server engine. The standard Python SocketServer
engine can also be used.
websocketproxy.py has been updated to match the API change. I've also
added a new option --libserver in order to use the Python built in
server instead.
I've done a lot of testing with the new code. This includes: verbose,
daemon, run-once, timeout, idle-timeout, ssl, web, libserver. I've
tested both Python 2 and 3. I've also tested websocket.py in another
external service.
Code details follows:
* The new request handler class is called WebSocketRequestHandler,
inheriting SimpleHTTPRequestHandler.
* The service engine is called WebSocketServer, just like before.
* do_websocket_handshake: Using send_header() etc, instead of manually
sending HTTP response.
* A new method called handle_websocket() upgrades the connection to
WebSocket, if requested. Otherwise, it returns False. A typical
application use is:
def do_GET(self):
if not self.handle_websocket():
# handle normal requests
* new_client has been renamed to new_websocket_client, in order to
have a better name in the SocketServer/HTTPServer request handler
hierarchy.
* Note that in the request handler, configuration variables must be
provided by the "server" object, ie self.server.target_host.
Should at least mostly address this issue:
https://github.com/kanaka/websockify/issues/63
The problem is that the target in the test case often immediately
closed the target after sending the data. In this case the last data
received from the target is never sent to the client because the
client is not in the list of sockets being selected against (because
it is only added if their is pending data). By moving the client
conditionals first, we give the client socket a chance to be sent data
before the target is detected as close and we terminate the loop.
Python ignores SIGPIPE on startup, because it prefers to check every
write and raise an IOError exception rather than taking the signal. Most
Unix subprocesses don't expect to work this way. This patch (adapted
from Colin Watson's post at http://tinyurl.com/2a7mzh5) sets SIGPIPE
back to the default action.
Pierre Ossman
Anders Kaseorg
Hermann Höhne
Michal Srb
Pierre Ossman
Solly Ross
samhed
Jose Ricardo Ziviani
Miguel Xavier Penha Neto
Solly Ross
Bennett Kanuka
Aric Stewart
Radek Podgorny
Peter Åstrand (astrand)
Alon Bar-Lev
Joel Martin
Vishvananda Ishaya