2017-05-14 09:48:41 +02:00
|
|
|
/************************************************************************
|
|
|
|
* This file has been generated automatically from *
|
|
|
|
* *
|
|
|
|
* src/core/qgsnetworkaccessmanager.h *
|
|
|
|
* *
|
|
|
|
* Do not edit manually ! Edit header and run scripts/sipify.pl again *
|
|
|
|
************************************************************************/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-01-25 11:00:50 +10:00
|
|
|
|
2019-01-30 07:48:48 +10:00
|
|
|
|
2019-01-22 08:18:46 +10:00
|
|
|
class QgsNetworkRequestParameters
|
|
|
|
{
|
|
|
|
%Docstring
|
|
|
|
Encapsulates parameters and properties of a network request.
|
|
|
|
|
|
|
|
.. versionadded:: 3.6
|
|
|
|
%End
|
|
|
|
|
|
|
|
%TypeHeaderCode
|
|
|
|
#include "qgsnetworkaccessmanager.h"
|
|
|
|
%End
|
|
|
|
public:
|
|
|
|
|
2019-01-25 11:00:50 +10:00
|
|
|
enum RequestAttributes
|
|
|
|
{
|
|
|
|
AttributeInitiatorClass,
|
|
|
|
AttributeInitiatorRequestId,
|
|
|
|
};
|
|
|
|
|
2019-01-22 08:18:46 +10:00
|
|
|
QgsNetworkRequestParameters();
|
|
|
|
%Docstring
|
|
|
|
Default constructor.
|
|
|
|
%End
|
|
|
|
|
|
|
|
QgsNetworkRequestParameters( QNetworkAccessManager::Operation operation,
|
2019-01-23 07:22:39 +10:00
|
|
|
const QNetworkRequest &request,
|
2019-01-24 22:11:49 +10:00
|
|
|
int requestId,
|
|
|
|
const QByteArray &content = QByteArray() );
|
2019-01-22 08:18:46 +10:00
|
|
|
%Docstring
|
|
|
|
Constructor for QgsNetworkRequestParameters, with the specified network
|
|
|
|
``operation`` and original ``request``.
|
|
|
|
%End
|
|
|
|
|
|
|
|
QNetworkAccessManager::Operation operation() const;
|
|
|
|
%Docstring
|
|
|
|
Returns the request operation, e.g. GET or POST.
|
|
|
|
%End
|
|
|
|
|
|
|
|
QNetworkRequest request() const;
|
|
|
|
%Docstring
|
|
|
|
Returns the network request.
|
|
|
|
|
|
|
|
This is the original network request sent to :py:class:`QgsNetworkAccessManager`, but with QGIS specific
|
|
|
|
configuration options such as proxy handling and SSL exceptions applied.
|
|
|
|
%End
|
|
|
|
|
|
|
|
QString originatingThreadId() const;
|
|
|
|
%Docstring
|
|
|
|
Returns a string identifying the thread which the request originated from.
|
2019-01-23 07:22:39 +10:00
|
|
|
%End
|
|
|
|
|
|
|
|
int requestId() const;
|
|
|
|
%Docstring
|
|
|
|
Returns a unique ID identifying the request.
|
2019-01-24 22:11:49 +10:00
|
|
|
%End
|
|
|
|
|
|
|
|
QByteArray content() const;
|
|
|
|
%Docstring
|
|
|
|
Returns the request's content. This is only used for POST or PUT operation
|
|
|
|
requests.
|
2019-01-25 11:00:50 +10:00
|
|
|
%End
|
|
|
|
|
|
|
|
QString initiatorClassName() const;
|
|
|
|
%Docstring
|
|
|
|
Returns the class name of the object which initiated this request.
|
|
|
|
|
|
|
|
This is only available for QNetworkRequests which have had the
|
|
|
|
QgsNetworkRequestParameters.AttributeInitiatorClass attribute set.
|
|
|
|
|
|
|
|
.. seealso:: :py:func:`initiatorRequestId`
|
|
|
|
%End
|
|
|
|
|
|
|
|
QVariant initiatorRequestId() const;
|
|
|
|
%Docstring
|
|
|
|
Returns the internal ID used by the object which initiated this request to identify
|
|
|
|
individual requests.
|
|
|
|
|
|
|
|
This is only available for QNetworkRequests which have had the
|
|
|
|
QgsNetworkRequestParameters.AttributeInitiatorRequestId attribute set.
|
|
|
|
|
|
|
|
.. seealso:: :py:func:`initiatorClassName`
|
2019-01-22 08:18:46 +10:00
|
|
|
%End
|
|
|
|
|
|
|
|
};
|
|
|
|
|
Make SSL error handling thread safe, avoid races and crashes when
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.
2019-01-27 20:29:26 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
2010-05-08 19:16:21 +00:00
|
|
|
class QgsNetworkAccessManager : QNetworkAccessManager
|
|
|
|
{
|
2017-05-14 09:48:41 +02:00
|
|
|
%Docstring
|
2018-05-26 14:10:30 +10:00
|
|
|
network access manager for QGIS
|
2017-12-15 10:36:55 -04:00
|
|
|
|
|
|
|
This class implements the QGIS network access manager. It's a singleton
|
|
|
|
that can be used across QGIS.
|
2017-05-14 09:48:41 +02:00
|
|
|
|
2017-12-15 10:36:55 -04:00
|
|
|
Plugins can insert proxy factories and thereby redirect requests to
|
|
|
|
individual proxies.
|
2017-05-14 09:48:41 +02:00
|
|
|
|
2017-12-15 10:36:55 -04:00
|
|
|
If no proxy factories are there or none returns a proxy for an URL a
|
|
|
|
fallback proxy can be set. There's also a exclude list that defines URLs
|
|
|
|
that the fallback proxy should not be used for, then no proxy will be used.
|
2018-05-28 11:31:08 -04:00
|
|
|
|
|
|
|
.. versionadded:: 1.5
|
2010-05-08 19:16:21 +00:00
|
|
|
%End
|
2012-09-24 02:28:15 +02:00
|
|
|
|
2017-05-14 09:48:41 +02:00
|
|
|
%TypeHeaderCode
|
|
|
|
#include "qgsnetworkaccessmanager.h"
|
|
|
|
%End
|
2010-05-09 00:45:17 +00:00
|
|
|
public:
|
2018-06-13 16:22:00 +02:00
|
|
|
|
|
|
|
static QgsNetworkAccessManager *instance( Qt::ConnectionType connectionType = Qt::BlockingQueuedConnection );
|
|
|
|
%Docstring
|
|
|
|
Returns a pointer to the active QgsNetworkAccessManager
|
|
|
|
for the current thread.
|
|
|
|
|
|
|
|
With the ``connectionType`` parameter it is possible to setup the default connection
|
|
|
|
type that is used to handle signals that might require user interaction and therefore
|
|
|
|
need to be handled on the main thread. See in-depth discussion below.
|
|
|
|
|
|
|
|
:param connectionType: In most cases the default of using a ``Qt.BlockingQueuedConnection``
|
2018-06-14 09:54:00 +02:00
|
|
|
is ok, to make a background thread wait for the main thread to answer such a request is
|
|
|
|
fine and anything else is dangerous.
|
|
|
|
However, in case the request was started on the main thread, one should execute a
|
|
|
|
local event loop in a helper thread and freeze the main thread for the duration of the
|
|
|
|
download. In this case, if an authentication request is sent from the background thread
|
|
|
|
network access manager, the background thread should be blocked, the main thread be woken
|
|
|
|
up, processEvents() executed once, the main thread frozen again and the background thread
|
|
|
|
continued.
|
2018-06-13 16:22:00 +02:00
|
|
|
%End
|
2010-05-08 19:16:21 +00:00
|
|
|
|
2017-05-14 09:48:41 +02:00
|
|
|
QgsNetworkAccessManager( QObject *parent = 0 );
|
2010-05-08 19:16:21 +00:00
|
|
|
|
Make SSL error handling thread safe, avoid races and crashes when
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.
2019-01-27 20:29:26 +10:00
|
|
|
|
2012-09-24 02:28:15 +02:00
|
|
|
void insertProxyFactory( QNetworkProxyFactory *factory /Transfer/ );
|
2017-05-14 09:48:41 +02:00
|
|
|
%Docstring
|
2019-01-30 05:51:55 +10:00
|
|
|
Inserts a ``factory`` into the proxy factories list.
|
|
|
|
|
|
|
|
Ownership of ``factory`` is transferred to the manager.
|
|
|
|
|
|
|
|
.. seealso:: :py:func:`removeProxyFactory`
|
|
|
|
|
|
|
|
.. seealso:: :py:func:`proxyFactories`
|
2017-05-14 09:48:41 +02:00
|
|
|
%End
|
2010-05-08 19:16:21 +00:00
|
|
|
|
2012-09-24 02:28:15 +02:00
|
|
|
void removeProxyFactory( QNetworkProxyFactory *factory /TransferBack/ );
|
2017-05-14 09:48:41 +02:00
|
|
|
%Docstring
|
2019-01-30 05:51:55 +10:00
|
|
|
Removes a ``factory`` from the proxy factories list.
|
|
|
|
|
|
|
|
.. seealso:: :py:func:`insertProxyFactory`
|
|
|
|
|
|
|
|
.. seealso:: :py:func:`proxyFactories`
|
2017-05-14 09:48:41 +02:00
|
|
|
%End
|
2010-05-08 19:16:21 +00:00
|
|
|
|
2012-09-24 02:28:15 +02:00
|
|
|
const QList<QNetworkProxyFactory *> proxyFactories() const;
|
2017-05-14 09:48:41 +02:00
|
|
|
%Docstring
|
2019-01-30 05:51:55 +10:00
|
|
|
Returns a list of proxy factories used by the manager.
|
|
|
|
|
|
|
|
.. seealso:: :py:func:`insertProxyFactory`
|
|
|
|
|
|
|
|
.. seealso:: :py:func:`proxyFactories`
|
2017-05-14 09:48:41 +02:00
|
|
|
%End
|
2010-05-08 19:16:21 +00:00
|
|
|
|
|
|
|
const QNetworkProxy &fallbackProxy() const;
|
2017-05-14 09:48:41 +02:00
|
|
|
%Docstring
|
2019-01-30 05:51:55 +10:00
|
|
|
Returns the fallback proxy used by the manager.
|
|
|
|
|
|
|
|
The fallback proxy is used for URLs which no other proxy factory returned proxies for.
|
|
|
|
|
|
|
|
.. seealso:: :py:func:`proxyFactories`
|
|
|
|
|
|
|
|
.. seealso:: :py:func:`setFallbackProxyAndExcludes`
|
2017-05-14 09:48:41 +02:00
|
|
|
%End
|
2010-05-08 19:16:21 +00:00
|
|
|
|
2017-01-14 13:46:26 +10:00
|
|
|
QStringList excludeList() const;
|
2017-05-14 09:48:41 +02:00
|
|
|
%Docstring
|
2019-01-30 05:51:55 +10:00
|
|
|
Returns the proxy exclude list.
|
|
|
|
|
|
|
|
This list consists of the beginning of URL strings which will not use the fallback proxy.
|
|
|
|
|
|
|
|
.. seealso:: :py:func:`fallbackProxy`
|
|
|
|
|
|
|
|
.. seealso:: :py:func:`setFallbackProxyAndExcludes`
|
2017-05-14 09:48:41 +02:00
|
|
|
%End
|
2012-09-24 02:28:15 +02:00
|
|
|
|
2010-05-08 19:16:21 +00:00
|
|
|
void setFallbackProxyAndExcludes( const QNetworkProxy &proxy, const QStringList &excludes );
|
2017-05-14 09:48:41 +02:00
|
|
|
%Docstring
|
2019-01-30 05:51:55 +10:00
|
|
|
Sets the fallback ``proxy`` and URLs which shouldn't use it.
|
|
|
|
|
|
|
|
The fallback proxy is used for URLs which no other proxy factory returned proxies for.
|
|
|
|
The ``excludes`` list specifies the beginning of URL strings which will not use this fallback proxy.
|
|
|
|
|
|
|
|
.. seealso:: :py:func:`fallbackProxy`
|
|
|
|
|
|
|
|
.. seealso:: :py:func:`excludeList`
|
2017-05-14 09:48:41 +02:00
|
|
|
%End
|
2010-05-09 21:35:31 +00:00
|
|
|
|
2017-02-21 18:14:58 +01:00
|
|
|
static QString cacheLoadControlName( QNetworkRequest::CacheLoadControl control );
|
2017-05-14 09:48:41 +02:00
|
|
|
%Docstring
|
2019-01-30 05:51:55 +10:00
|
|
|
Returns the name for QNetworkRequest.CacheLoadControl.
|
|
|
|
|
|
|
|
.. seealso:: :py:func:`cacheLoadControlFromName`
|
2017-05-14 09:48:41 +02:00
|
|
|
%End
|
2014-01-26 18:35:21 +01:00
|
|
|
|
2017-02-21 18:14:58 +01:00
|
|
|
static QNetworkRequest::CacheLoadControl cacheLoadControlFromName( const QString &name );
|
2017-05-14 09:48:41 +02:00
|
|
|
%Docstring
|
2019-01-30 05:51:55 +10:00
|
|
|
Returns QNetworkRequest.CacheLoadControl from a ``name``.
|
|
|
|
|
|
|
|
.. seealso:: :py:func:`cacheLoadControlName`
|
2017-05-14 09:48:41 +02:00
|
|
|
%End
|
2014-01-26 18:35:21 +01:00
|
|
|
|
2018-05-24 13:36:04 +02:00
|
|
|
void setupDefaultProxyAndCache( Qt::ConnectionType connectionType = Qt::BlockingQueuedConnection );
|
2017-05-14 09:48:41 +02:00
|
|
|
%Docstring
|
2018-06-13 16:22:00 +02:00
|
|
|
Setup the QgsNetworkAccessManager (NAM) according to the user's settings.
|
|
|
|
The ``connectionType`` sets up the default connection type that is used to
|
|
|
|
handle signals that might require user interaction and therefore
|
|
|
|
need to be handled on the main thread. See in-depth discussion in the documentation
|
|
|
|
for the constructor of this class.
|
2017-05-14 09:48:41 +02:00
|
|
|
%End
|
2014-05-27 23:22:50 +02:00
|
|
|
|
2016-06-12 13:47:21 +02:00
|
|
|
bool useSystemProxy() const;
|
2017-05-14 09:48:41 +02:00
|
|
|
%Docstring
|
2019-01-30 05:51:55 +10:00
|
|
|
Returns whether the system proxy should be used.
|
2019-01-30 05:59:37 +10:00
|
|
|
%End
|
|
|
|
|
|
|
|
static int timeout();
|
|
|
|
%Docstring
|
|
|
|
Returns the network timeout length, in milliseconds.
|
|
|
|
|
|
|
|
.. seealso:: :py:func:`setTimeout`
|
|
|
|
|
|
|
|
.. versionadded:: 3.6
|
|
|
|
%End
|
|
|
|
|
|
|
|
static void setTimeout( int time );
|
|
|
|
%Docstring
|
|
|
|
Sets the maximum timeout ``time`` for network requests, in milliseconds.
|
|
|
|
|
|
|
|
.. seealso:: :py:func:`timeout`
|
|
|
|
|
2019-01-30 07:48:48 +10:00
|
|
|
.. versionadded:: 3.6
|
|
|
|
%End
|
|
|
|
|
|
|
|
static QgsNetworkReplyContent blockingGet( QNetworkRequest &request, const QString &authCfg = QString(), bool forceRefresh = false, QgsFeedback *feedback = 0 );
|
|
|
|
%Docstring
|
|
|
|
Posts a GET request to obtain the contents of the target request and returns a new QgsNetworkReplyContent object for reading.
|
|
|
|
The current thread will be blocked until the request is returned.
|
|
|
|
|
|
|
|
This method is safe to call in either the main thread or a worker thread.
|
|
|
|
|
|
|
|
If ``forceRefresh`` is false then previously cached replies may be used for the request. If
|
|
|
|
it is set to true then a new query is always performed.
|
|
|
|
|
|
|
|
If an ``authCfg`` has been specified, then that authentication configuration required will automatically be applied to
|
|
|
|
``request``. There is no need to manually apply the authentication to the request prior to calling
|
|
|
|
this method.
|
|
|
|
|
|
|
|
The optional ``feedback`` argument can be used to abort ongoing requests.
|
|
|
|
|
|
|
|
The contents of the reply will be returned after the request is completed or an error occurs.
|
|
|
|
|
|
|
|
.. seealso:: :py:func:`blockingPost`
|
|
|
|
|
|
|
|
.. versionadded:: 3.6
|
|
|
|
%End
|
|
|
|
|
|
|
|
static QgsNetworkReplyContent blockingPost( QNetworkRequest &request, const QByteArray &data, const QString &authCfg = QString(), bool forceRefresh = false, QgsFeedback *feedback = 0 );
|
|
|
|
%Docstring
|
|
|
|
Posts a POST request to obtain the contents of the target ``request``, using the given ``data``, and returns a new
|
|
|
|
QgsNetworkReplyContent object for reading. The current thread will be blocked until the request is returned.
|
|
|
|
|
|
|
|
This method is safe to call in either the main thread or a worker thread.
|
|
|
|
|
|
|
|
If ``forceRefresh`` is false then previously cached replies may be used for the request. If
|
|
|
|
it is set to true then a new query is always performed.
|
|
|
|
|
|
|
|
If an ``authCfg`` has been specified, then that authentication configuration required will automatically be applied to
|
|
|
|
``request``. There is no need to manually apply the authentication to the request prior to calling
|
|
|
|
this method.
|
|
|
|
|
|
|
|
The optional ``feedback`` argument can be used to abort ongoing requests.
|
|
|
|
|
|
|
|
The contents of the reply will be returned after the request is completed or an error occurs.
|
|
|
|
|
|
|
|
.. seealso:: :py:func:`blockingGet`
|
|
|
|
|
2019-01-30 05:59:37 +10:00
|
|
|
.. versionadded:: 3.6
|
2017-05-14 09:48:41 +02:00
|
|
|
%End
|
2014-05-27 23:22:50 +02:00
|
|
|
|
2010-05-09 21:35:31 +00:00
|
|
|
signals:
|
2019-01-23 07:41:29 +10:00
|
|
|
|
|
|
|
void requestAboutToBeCreated( QNetworkAccessManager::Operation, const QNetworkRequest &, QIODevice * ) /Deprecated/;
|
|
|
|
%Docstring
|
|
|
|
|
|
|
|
.. deprecated:: Use the thread-safe requestAboutToBeCreated( QgsNetworkRequestParameters ) signal instead.
|
|
|
|
%End
|
2019-01-22 08:18:46 +10:00
|
|
|
|
|
|
|
void requestAboutToBeCreated( QgsNetworkRequestParameters request );
|
|
|
|
%Docstring
|
|
|
|
Emitted when a network request is about to be created.
|
|
|
|
|
|
|
|
This signal is propagated to the main thread QgsNetworkAccessManager instance, so it is necessary
|
|
|
|
only to connect to the main thread's signal in order to receive notifications about requests
|
|
|
|
created in any thread.
|
|
|
|
|
2019-01-23 05:35:09 +10:00
|
|
|
.. seealso:: :py:func:`finished`
|
|
|
|
|
2019-01-23 07:34:26 +10:00
|
|
|
.. seealso:: :py:func:`requestTimedOut`
|
|
|
|
|
2019-01-23 05:35:09 +10:00
|
|
|
.. versionadded:: 3.6
|
|
|
|
%End
|
|
|
|
|
|
|
|
void finished( QgsNetworkReplyContent reply );
|
|
|
|
%Docstring
|
|
|
|
This signal is emitted whenever a pending network reply is finished.
|
|
|
|
|
|
|
|
The ``reply`` parameter will contain a QgsNetworkReplyContent object, containing all the useful
|
|
|
|
information relating to the reply, including headers and reply content.
|
|
|
|
|
|
|
|
This signal is propagated to the main thread QgsNetworkAccessManager instance, so it is necessary
|
|
|
|
only to connect to the main thread's signal in order to receive notifications about requests
|
|
|
|
created in any thread.
|
|
|
|
|
|
|
|
.. seealso:: :py:func:`requestAboutToBeCreated`
|
|
|
|
|
2019-01-23 07:34:26 +10:00
|
|
|
.. seealso:: :py:func:`requestTimedOut`
|
|
|
|
|
|
|
|
.. versionadded:: 3.6
|
|
|
|
%End
|
|
|
|
|
|
|
|
void requestTimedOut( QgsNetworkRequestParameters request );
|
|
|
|
%Docstring
|
|
|
|
Emitted when a network request has timed out.
|
|
|
|
|
|
|
|
This signal is propagated to the main thread QgsNetworkAccessManager instance, so it is necessary
|
|
|
|
only to connect to the main thread's signal in order to receive notifications about requests
|
|
|
|
created in any thread.
|
|
|
|
|
|
|
|
.. seealso:: :py:func:`requestAboutToBeCreated`
|
|
|
|
|
|
|
|
.. seealso:: :py:func:`finished`
|
|
|
|
|
2019-01-25 10:08:36 +10:00
|
|
|
.. versionadded:: 3.6
|
|
|
|
%End
|
|
|
|
|
|
|
|
void downloadProgress( int requestId, qint64 bytesReceived, qint64 bytesTotal );
|
|
|
|
%Docstring
|
|
|
|
Emitted when a network reply receives a progress report.
|
|
|
|
|
|
|
|
The ``requestId`` argument reflects the unique ID identifying the original request which the progress report relates to.
|
|
|
|
|
|
|
|
The ``bytesReceived`` parameter indicates the number of bytes received, while ``bytesTotal`` indicates the total number
|
|
|
|
of bytes expected to be downloaded. If the number of bytes to be downloaded is not known, ``bytesTotal`` will be -1.
|
|
|
|
|
|
|
|
This signal is propagated to the main thread QgsNetworkAccessManager instance, so it is necessary
|
|
|
|
only to connect to the main thread's signal in order to receive notifications about requests
|
|
|
|
created in any thread.
|
|
|
|
|
2019-01-29 15:40:42 +10:00
|
|
|
.. versionadded:: 3.6
|
|
|
|
%End
|
|
|
|
|
|
|
|
void requestRequiresAuth( int requestId, const QString &realm );
|
|
|
|
%Docstring
|
|
|
|
Emitted when a network request prompts an authentication request.
|
|
|
|
|
|
|
|
The ``requestId`` argument reflects the unique ID identifying the original request which the authentication relates to.
|
|
|
|
|
|
|
|
This signal is propagated to the main thread QgsNetworkAccessManager instance, so it is necessary
|
|
|
|
only to connect to the main thread's signal in order to receive notifications about authentication requests
|
|
|
|
from any thread.
|
|
|
|
|
|
|
|
This signal is for debugging and logging purposes only, and cannot be used to respond to the
|
|
|
|
requests. See QgsNetworkAuthenticationHandler for details on how to handle authentication requests.
|
|
|
|
|
2019-01-29 19:47:11 +10:00
|
|
|
.. seealso:: :py:func:`requestAuthDetailsAdded`
|
|
|
|
|
|
|
|
.. versionadded:: 3.6
|
|
|
|
%End
|
|
|
|
|
|
|
|
void requestAuthDetailsAdded( int requestId, const QString &realm, const QString &user, const QString &password );
|
|
|
|
%Docstring
|
|
|
|
Emitted when network authentication details have been added to a request.
|
|
|
|
|
|
|
|
The ``requestId`` argument reflects the unique ID identifying the original request which the authentication relates to.
|
|
|
|
|
|
|
|
This signal is always sent from the main thread QgsNetworkAccessManager instance, so it is necessary
|
|
|
|
only to connect to the main thread's signal in order to receive notifications about authentication requests
|
|
|
|
from any thread.
|
|
|
|
|
|
|
|
This signal is for debugging and logging purposes only, and should not be used to respond to the
|
|
|
|
requests. See QgsNetworkAuthenticationHandler for details on how to handle authentication requests.
|
|
|
|
|
|
|
|
.. seealso:: :py:func:`requestRequiresAuth`
|
|
|
|
|
2019-01-22 08:18:46 +10:00
|
|
|
.. versionadded:: 3.6
|
|
|
|
%End
|
|
|
|
|
Make SSL error handling thread safe, avoid races and crashes when
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.
2019-01-27 20:29:26 +10:00
|
|
|
|
|
|
|
void requestEncounteredSslErrors( int requestId, const QList<QSslError> &errors );
|
|
|
|
%Docstring
|
|
|
|
Emitted when a network request encounters SSL ``errors``.
|
|
|
|
|
2019-01-29 15:40:42 +10:00
|
|
|
The ``requestId`` argument reflects the unique ID identifying the original request which the SSL error relates to.
|
Make SSL error handling thread safe, avoid races and crashes when
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.
2019-01-27 20:29:26 +10:00
|
|
|
|
|
|
|
This signal is propagated to the main thread QgsNetworkAccessManager instance, so it is necessary
|
|
|
|
only to connect to the main thread's signal in order to receive notifications about SSL errors
|
|
|
|
from any thread.
|
|
|
|
|
2019-01-29 15:40:42 +10:00
|
|
|
This signal is for debugging and logging purposes only, and cannot be used to respond to the errors.
|
|
|
|
See QgsSslErrorHandler for details on how to handle SSL errors and potentially ignore them.
|
|
|
|
|
Make SSL error handling thread safe, avoid races and crashes when
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.
2019-01-27 20:29:26 +10:00
|
|
|
.. versionadded:: 3.6
|
|
|
|
%End
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-01-23 07:41:29 +10:00
|
|
|
void requestCreated( QNetworkReply * ) /Deprecated/;
|
|
|
|
%Docstring
|
|
|
|
|
|
|
|
.. deprecated:: Use the thread-safe requestAboutToBeCreated( QgsNetworkRequestParameters ) signal instead.
|
|
|
|
%End
|
|
|
|
|
2014-05-27 23:22:50 +02:00
|
|
|
void requestTimedOut( QNetworkReply * );
|
2016-01-04 22:51:18 +11:00
|
|
|
|
Make SSL error handling thread safe, avoid races and crashes when
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.
2019-01-27 20:29:26 +10:00
|
|
|
|
2019-01-29 15:40:42 +10:00
|
|
|
|
2010-05-09 21:35:31 +00:00
|
|
|
protected:
|
2012-09-24 02:28:15 +02:00
|
|
|
virtual QNetworkReply *createRequest( QNetworkAccessManager::Operation op, const QNetworkRequest &req, QIODevice *outgoingData = 0 );
|
|
|
|
|
2017-12-15 08:57:22 +10:00
|
|
|
|
2010-05-08 19:16:21 +00:00
|
|
|
};
|
2017-05-14 09:48:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
/************************************************************************
|
|
|
|
* This file has been generated automatically from *
|
|
|
|
* *
|
|
|
|
* src/core/qgsnetworkaccessmanager.h *
|
|
|
|
* *
|
|
|
|
* Do not edit manually ! Edit header and run scripts/sipify.pl again *
|
|
|
|
************************************************************************/
|