not possible to use Websocket as a client with a self-signed server certificate about tufao HOT 7 CLOSED

I suggest a new method WebSocket::setExpectedSslErrors(QList&) which would store the list in a member variable. In case all the error codes of SSL errors QT reports in WebSocket::onSslErrors are in the expected list, call qobject_cast<QSslSocket*>(sender())->ignoreSslErrors(m_ignoreList), otherwise do what it does now.

I don't like this idea. It's a specific behaviour and I add a new method. Then your have another specific need and another method is required.

I want a flexible solution that fit in your needs. What do you think about add startClientHandshake(QAbstractSocket *socket) or somethink like that?

from tufao.

I understand your desire to keep the API simple.

There are many ways to enable Tufao (sorry, can't find that special character above a :) to be used with self-signed server certificates. If you don't want to add a new method, you could systematically ignore all SSL errors, or have a hard-coded list of what to ignore. The drawback here is that the users may want to have control over it.

If you decide to change the interface and don't want to expose QSslSocket or QSslError, one option could be a configuration flag indicating the user wants to ignore ssl errors related to self-signed certificate. One could be re-emitting the sslErrors signal with the QSslSocket* as parameter. With the latter, users

About adding startClientHandshake(QAbstractSocket *socket) - the name is a bit inconsistent because the existing startServerHandshake is about the websocket protocol and here we are dealing with SSL. Also the QT socket is internal to the Websocket class and QT deals internally with SSL handshakes, we just need to call socket->connectToHostEncrypted and handle the sslErrors() and encrypted() signals. If you add such a method all existing calling code would need to be changed. If you only add a way to ignore certain SSL errors, only users that need to do such a thing will need to add a line of code and others have no impact.

This is a common problem that pretty much all libraries implementing SSL client have to deal with (e.g. libcurl has CURLOPT_SSL_VERIFYPEER, QXmpp has setIgnoreSslErrors(bool) etc). You can easily reproduce it by e.g. running the https-example in Tufao and try to use Websocket as a client connecting to it.

from tufao.

If you don't want to add a new method, you could systematically ignore all SSL errors, or have a hard-coded list of what to ignore. The drawback here is that the users may want to have control over it.

I want to delegate the responsability of special behaviour to the user.

If you decide to change the interface and don't want to expose QSslSocket or QSslError, one option could be a configuration flag indicating the user wants to ignore ssl errors related to self-signed certificate.

This option seems still more restrictive.

One could be re-emitting the sslErrors signal with the QSslSocket* as parameter. With the latter, users

The purpose of this behaviou would be to let the user have access to socket object and arbitrarily configure it. If I choose this option, its intent should be more explicit (such as the previous startClientHandshake(QAbstractSocket*) idea).

About adding startClientHandshake(QAbstractSocket *socket) - the name is a bit inconsistent because the existing startServerHandshake is about the websocket protocol and here we are dealing with SSL.

This method would deal with WebSocket handshake. You'd deal with connection and WebSocket in different phases:

1. Create, configure and connect a socket.
2. Pass the socket in connected state to the WebSocket object.

Also the QT socket is internal to the Websocket class and QT deals internally with SSL handshakes, we just need to call socket->connectToHostEncrypted and handle the sslErrors() and encrypted() signals. If you add such a method all existing calling code would need to be changed.

Handle SSL Errors differently is a application special need, not a general purpose behaviour that should be implemented in WebSocket handling code.

If you only add a way to ignore certain SSL errors, only users that need to do such a thing will need to add a line of code and others have no impact.

I still don't like this idea, but I understand that is a limitation that need to be overcomed.

The impact of the change would be smaller if I limit the surface of interaction to the moment you want to connect to the server. This can be done adding an extra optional argument (or an overloaded method) to connectToHostEncrypted. This extra argument could be the mentioned list of ignored ssl errors. What do you think about this idea?

I'll the startClientHandshake if another special need arise.

from tufao.

The purpose of this behaviour would be to let the user have access to socket object and arbitrarily configure it. If I choose this option, its intent should be more explicit (such as the previous startClientHandshake(QAbstractSocket*) idea).
This method would deal with WebSocket handshake. You'd deal with connection and WebSocket in different phases:

1. Create, configure and connect a socket.
2. Pass the socket in connected state to the WebSocket object.

OK, I see what you mean now.

As a user of the class I would prefer the optional extra argument to connectToHostEncrypted solution. I don't like the idea of writing two versions just to be able to run the code against a development server with a self-signed certificate.and a production server with a real one.

In principle you are right though, if the user would have a need to do some special tricks on the socket that would be a clean way to delegate that responsibility.

from tufao.

@tpatja, we got a winner. I'll put the extra optional argument, but I have too many tests at university tomorrow and after tomorrow. I'll have at least friday free to put this change, but this change is so small that maybe I'll be able to add it right tomorrow.

from tufao.

Ok, great.

from tufao.

Fixed in this commit.

Version 0.7 released with the change.

from tufao.