Events from the crash reporter suggest that the QNAM and its
child replies might get deleted before returning from this method
and the only possible cause we can see is that the inner event
loop has something to do with it.
Try keeping a ref on the QNAM while in this method to make sure
that it won't get deleted by the inner event loop.
Previously rejecting any kind of certificate meant that the user
was never asked again, even if the certificate changed.
Now we keep track of which certificates were rejected and ask again
if the ones mentioned in the ssl errors change.
mitmproxy is excellent for testing this.
This will be useful if we ever want to store account-level gui state.
I built this originally because I thought a paused account would be
this kind of state.
This moves the responsibility of asking the user or not for
credentials from the Credentials classes back to the AccountState.
fetch() now only extract credentials from the keychain, reports
the result to the AccountState which then decides if askFromUser()
should be called or not. The result is once more reported to the
AccounState.
This also replaces the HttpCredentials::queryPassword virtual
which now lets HttpCredentialsGui and HttpCredentialsText do it
the way that they prefer.
The AccountState is now the only class responsible for triggering credentials
fetching from the keychain or from the user.
With the ShibbolethRefresher out of the question it's possible
to remove the invalidateAndFetch virtual and manually call invalidateToken.
This also allows us to move that code from Account to AccountState.
In the end this also allows us to move the fetch() call from the
ConnectionValidator and use the same code path as for invalid credentials.
- Remove the copy constructor. The default constructor is fine. Having
a user defined copy constructor inhibit the move constructor.
- Pass QVariantMap arguments via const references
- Do not return a pointer to Capabilities from the account. It is a
value type and should not be used by pointer.
The proxyAuthenticationRequired() signal now goes to the
ProxyAuthHandler class. That class will try to read the proxy settings
from the keychain or ask the user about them.
We won't ask the user for credentials for explicitly configured proxies.
It also does not change how the credentials for explicitly configured
proxies are stored. (see #261)
Since we periodically recreatet the QNAM owned by the Account,
the web view could end up holding a dangling pointer to it.
Let the web view use its own QNAM, but make sure that the cookie
jars are shared so that we can grab the session token given
by the server.
