mirror of
https://github.com/qgis/QGIS.git
synced 2025-03-09 00:35:20 -05:00
2e3a717e44
SSL error occurs in non-main thread This commit reworks how SSL errors are handled in QGIS. Previously, ssl errors emitted by non-main thread QgsNetworkAccessManager instances were handled by the main thread in QgisApp on next event loop. But app (in the main thread) tried to pause the timeout timer for the QNetworkReply containing the error, which doesn't work, because you can't stop a timer in the main thread for a timer object created in another thread. This meant that the reply could get deleted in the background thread while the main thread was still using it and waiting for users to respond to the SSL error. Now the timer handling is done in the background thread's network access manager instance, so in the thread matching the reply's timeout timer. We then have to do some fancy thread locking using QWaitCondition, because we need to "pause" that thread until the SSL error is handled in the main thread -- if we don't pause the background thread, Qt immediately resumes the QNetworkReply without ever giving us the change to ignore ssl errors in the reply. Phew! Additionally, the previous approach had a shortcoming in that there was no way to notify background threads that ssl errors had actually be handled. To do this we need a new signal which can be fired after app has shown the ssl dialog and given users a chance to respond. BUT... we can't safely do this -- if we add a method to notify background threads when ssl errors have been handled, then it CANNOT safely reside in app -- doing so would break for QGIS server and QField etc, where theres no app instance around to provide this notification. As a result I've abstracted out the ssl error handling. By default there's a simple error handler which just logs errors and returns without ignoring them (i.e. default Qt behavior, an ssl error cancels the request). App has a specific subclass of the ssl error handler which presents the nice dialog and asks users to choose what to do. Potentially server could decide to make its own subclass too, which could e.g. ignore SSL warnings if an environment variable is present (but at the moment the behavior is effectively unchanged for server). The end result is that SSL error handling should now be totally thread safe, and we shouldn't hit any more deadlocks and crashes when ssl errors occur in background threads. I've also taken the opportunity to add a new signal which is always emitted by the main thread QgsNetworkAccessManager instance, which is emitted whenever ANY request on any thread encounters an SSL error, and contains the requestId so that the ssl error can be linked back to the originating request. This is for debugging, and for use by the network monitoring plugin to show ssl errors encountered by requests.