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
When Cura is starting up, it reads the authentication data from the preferences (cura.cfg). If
the auth tokens have previously been stored in the keyring, it means that their values will be null
in the cura.cfg file. Therefore, on startup, Cura reads the tokens as none from the preferences and
then sets the empty values in the keyring as tokens. This leads to the user being signed off every
time Cura restarts on Mac.
On Windows, the access token was still stored in the preferences, so on startup it was safe. The
refresh token, on the other hand, had the same issue as on Mac, which means that on startup it was
read as None from the cura.cfg and was stored in the keyring as an empty string. This meant that,
even though on startup (on windows) the user was kept signed in, the next time Cura was attempting
to refresh the access token (after 7-8 minutes), it wouldn't be able, since its refresh token was
read as "" from the keyring. Also, if the user would close Cura and reopen it after 10 minutes
(so after the access token had expired) then they would be signed off on windows too.
This commit fixes that by making sure that if the given value of the refresh and access tokens are
empty, then they will not be stored in the keyring.
CURA-8178
Write an empty string as value to the keyring if None is parsed and
return a None value if an empty string was parsed from the keyring.
CURA-7180_keyring_none_value
So there is an issue with keyring w.r.t. frozen installs (maybe also local). If you have pywin32 installed, it works fine locally. Take a note here, that a variant of this package, pywin32-ctypes, a rudimentary version of that package that works wholly within python, is already installed as its a dependency for keyring on windows. Due to an unknown reason, when running it fails to detect this, so some workaround is needed, _or_ the 'normal' pywin32 package should be installed. However, problems occurred when attempts where made to install pywin32 via cx_freeze. Then the actual workaround was encountered (https://github.com/jaraco/keyring/issues/468), which _should_ hopefully let use use the keyring on windows without needing the 'full' version of pywin32.
CURA-7180
The Windows Credential Manager allows for up to 256bits passwords. If a password longer than that
is attempted to be written, it will throw a BaseException.
CURA-7180
