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
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 thread handling the web_server was crashing. This in turn ended in
the web_server not being able to start again, thus being impossible to
login again if you logged out.
Surround the serve_forever function of the web server with a try-catch
on Windows, in order to avoid printing the entire (useless) traceback.
Now a warning message is be displayed in the log instead.
The behavior is untouched in other platforms
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
* Fix PermissionError when importing http.server
Instead of crashing, now it'll just not start the server. This means that you won't be able to receive the response from the log-in so you won't be able to log in. The browser gives an error that it can't find the page on localhost. But at least it doesn't crash.
Fixes crash CURA-3Q.
* Log an error when the HTTP server can't be started
Contributes to crash CURA-3Q.
* Indicate that types are optional
Attempt to fix the typing issue with MyPy. I can't run this locally so the CI server will have to tell me if this fixed it.
Contributes to Sentry issue CURA-3Q.
It's mostly a theoretical problem, but 16 could theoretically be brute
forced. Bumping it up to 32 won't break anything, but it does make it
exteremely unlikely that it gets broken
