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.
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.
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 class will handle the storing and processing
of secrets. Such as tokens. It will try to use the system
keyring by default. Falling back to less secure methods,
if the user doesn't allow access to the keyring or if
the back-end is unsupported.
CURA-7180 keyring storage
We're getting some reports that people are suddenly logged out. The working
theory is that they are mixing staging & production builds. This logging
should tell us enough to find out if that is the case!
JSON dictionaries need to have a certain structure such as strings as keys. If that's not correct it gives a TypeError. Don't crash on those; give a similar error message as when the values in the JSON are invalid.
Windows won't allow long keys in the backend the keyring python package uses as a backend. This means the access_token part can't be stored in the obvious way. Timeboxed some attempts at working around this limitation, but couldn't make it work within the time set. As this is mostly an extra precaustion protecting users that share config folders around against themselves (in other words, if this goes wrong it's not unreasonable to blame the user) it's not top critical, and the important part of that (the refresh_token) can proceed, giving any potential attacker only a 10 minute window from the moment any user shares their %appdata%/cura files (again, this is not how we intent for users to behave, but they can and will do it this way).
CURA-7180
The authentication link should be prepended with a logoff link from
mycloud, if it is requested. In order to make this process testable
this commit separates the generation of the authentication link,
based on whether it requests for a browser logoff first, into its
own function.
This commit also adds tests for this function.
CURA-7427
There are cases where Cura and the browser fall out of sync when it
comes to accounts. In such cases, you may be logged in cura with an
account that has no cloud printers and in the browser with an account
that has printers. So when you press the "Add cloud printer" button,
you are redirected to mycloud and you see cloud printers that are not
detected by Cura (because Cura is in a different acconut). In such
cases, the user can now press the "Sign in with a different account"
link in the "Waiting for cloud response" page, which will log him/her
out in Cura AND in the browser, and then reinitiate the whole
authorization flow, to make sure the accounts are in sync.
CURA-7427
