--ssl-version takes two possible values (tlsv1_1, tlsv1_2). Defaults
to tlsv1_1.
--ssl-ciphers takes allowed ciphers in the same format as
`openssl ciphers`.
Added options for 1.3 and the default ssl config
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>
Pierre Ossman
Giuseppe Corbelli
Tommy Brunn
josedpedroso
Tomasz Barański
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