We're confident now that we get it to not crash for most normal cases. If there is a crash here it's due to the internals of Keyring. We're catching all of the others separately anyway.
Fixes Sentry issue CURA-340.
This occurs when there's a timeout, on some systems, when asking for the password to the keyring. We'll interpret a timeout as a refusal to enter a password.
Fixes Sentry issue CURA-332.
If two requests to the API occur at the same time, they will both see at the same time that they need an access token, and if it is expired they will both see that it needs refreshing. The server then sees two refreshes, both with the same refresh token. This is not allowed. The second one then gets a failure to refresh the token, which causes the user to log out.
Instead, we'll stop one of the refresh requests. They were fire-and-forget anyway, so it's not needed to actually continue the request.
Contributes to issue CURA-8539.
It gives two parameters, additionally an error code. However our callback wrapper gets the error code from the reply itself so it doesn't need it.
Contributes to issue CURA-8539.
Because not having auth data is a reason to return no profile too. Otherwise the other side might wait for a response for a long time.
Contributes to issue CURA-8539.
It provides 2 arguments (reply and error) which we both ignore and proceed to call failed_callback. And failed_callback may also be None in which case we don't call anything.
Contributes to issue CURA-8539.
As a result, the local webserver now needs to synchronise that with a lock. Otherwise the do_GET function would no longer block, and wouldn't properly be able to return the correct redirect URL.
Contributes to issue CURA-8539.
Now it calls checkToken correctly. However now this _parseJWT is not called correctly since there are things calling this one in an attempt to be synchronous again.
There is the additional issue that we can't call getAccessTokenUsingRefreshToken synchronously now, because this runs on the main thread and it will then block the main thread until the request is made, which is never because the request is also done on the main thread via Qt's event loop.
Contributes to issue CURA-8539.
This involves returning the user profile via a callback.
No longer use the Requests library, which doesn't properly use the SSL certificates locally on the computer like the QNetworkManager does.
Contributes to issue CURA-8539.
This is a re-write from a previous attempt. Instead of requests, which doesn't properly use SSL certificates installed on the computer among other things, we'll now use the HttpRequestManager which uses QNetworkManager under the hood and properly uses system settings.
The QNetworkManager is asynchronous which would normally be very nice, but due to the nature of this call we want to make it synchronous so we'll use a lock here.
Contributes to issue CURA-8539.
Turns out that when the KeychainDenied error is raised, it is being caught by the macOS keyring api and the non-macOS-specific KeyringLocked error is raised instead, so we need to catch this one.
CURA-8332
