The actual profile is not necessary for this test. But this function always returns None and we shouldn't patch it to make it return something else.
Contributes to issue CURA-8539.
We're no longer generating that error. We're generating a QNetworkReply with a built-in error code and those errors are handled the same way as the failed requests tested above.
Contributes to issue CURA-8539.
It was previously mocking some return values that should now get returned via callbacks. And it was previously relying on a web service which might not connect at all.
Contributes to issue CURA-8539.
The reply is not really relevant. The reply is mocked through readJSON.
So it turns out that so far, our tests have been making actual requests to the authentication server, and depended on it being online. Not good. Mock those external dependencies!
Contributes to issue CURA-8539.
In this case the callback should get called immediately (no wait) so it is safe to test for this callback, albeit slightly implementation-defined.
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.
We can't change this index to an integer, because varying variables can't be integer, even though this variable will only really be tested on vertex level. Not sure if varying was the right choice, but I don't want to change that.
This prevents a crash, probably only occurring on certain GPUs.
Contributes to issue CURA-8657.
There is no theoretical or algorithmic limit here. We may warn the user, but not prevent them from changing it.
Done as a five minute fix. Fixes CURA-8693. Fixes#10736.
This is very annoying if switching profiles. This is not a critical message. The message should disappear after the default amount of time.
Discovered while working on CURA-8584.