The 0.2.0 release tag is not reflected and versioning fields are not updated anywhere anyway.
This commit rectifies at least the latter problem: application versions are now updated where they appear in code/manifests.
This change implements necessary control flow to pick up on accounts being passed to Keysmith via commandline options.
This change covers UX only for the happy flow case in which the received account is a valid otpauth:// URI.
If such an URI is passed to Keysmith, then the Add Account form is automatically pushed on the page stack and pre-populated with data received from the commandline.
With this UX, if the account is valid the user may either accept it immediately or tweak settings (most likely account name/issuer) to make it valid.
Issues: #7, #14
Users may now cancel adding an account and dismiss the page.
This change is particularly relevant in the context of an account that is being added via URI passed on the commandline: the user may now explicitly reject it.
Additionally quitting Keysmith from the add account form is now also supported, hidden behding a boolean flag.
This will be useful for the initial page when receiving an account via URI from the commandline: the user may reject the account and quit Keysmith via a single action.
Issues: #7, #14
This page is a bit of a bodge for the fact that the current Accounts model must be 'unlocked' before it can be used.
In turn, this means that it is not straightforward to check that an account is still 'available' when presenting the user with the option to add an account received via URI from the commandline.
The solution implemented here is to check and let the user recover after unlocking, if necessary.
Issues: #7, #14
This new component can be used to inject an interstitial page, letting the user know something went wrong and allowing them to decide whether to continue or to quit Keysmith.
This is especially useful when Keysmith was launched automatically from some other context (i.e. another app) without the user necessarily being fully aware of it.
Issues: #7, #14
With this change AccountNameValidator can now be used without having a functional Accounts model.
This allows the existing AddAccount page to be re-used for context without a valid Accounts model, e.g. when receiving accounts via URI from the commandline.
Issues: #7, #14
With this change top-level QML code may pass a (populated) ValidatedAccountInput object to pre-populate fields in the add account forms.
Issues: #7, #14
Being able to reset an account input model to the default state allows for QML UI to safely reuse an account input.
This lets it delegate populating to other code and then finally forward it to other QML code when control returns to the UI.
Issues: #7, #14
This change is a building block towards receiving decoded QR codes from other applications and adding corresponding accounts in Keysmith.
Issues: #7, #14
Add support converting an otpauth:// URI into a model object.
Validation is quite lax and focused on what Keysmith can recover from within the scope of UI/UX for adding accounts via QR codes.
See-Also: https://github.com/google/google-authenticator/wiki/Key-Uri-Format
Issues: #14
This change provides a bare minimum implementation to parse an otpauth:// type URI into its component parts.
Parsing is quite lax, and focused on what Keysmith can support or recover from in the intended UI/UX for adding accounts via QR codes.
See-Also: https://github.com/google/google-authenticator/wiki/Key-Uri-Format
Issues: #14
One downside of offloading the token computation to a worker thread and having to do token decryption is an increase in latency.
For the case with a few accounts this latency does not matter, but in case of many accounts it can induce a significant delay when refreshing tokens in the UI.
To hide this latency, when computing an OTP token for the current state of the account the logical 'next' token is also computed as well and cached in the Account object.
When the next (re)computation of the OTP token is requested, the cached 'next' value is reused if still valid before the next pair of tokens is being computed.
This way the apparent latency of a token update is reduced to an near immediate property update in the UI, hiding the actual latency of the computation itself.
This 'optimisation' is implemented in the dumbest possible fashion that can still work.
This means that the code complexity of the change is quite limited, at the cost of rougly doubling the actual work being performed in the worker thread.
Previously a user could accidentally trigger an additional 'add account' action even when the action (button) was not visible in the UI.
This oversight is now fixed.
- Introduce re-usable account name + issuer form. This will help to support overriding account name/issuer when adding accounts via OTP token URI/QR code
- Move common settings out of TokenDetailsForm into AddAccount.qml
Issues: #7
This change prepares the UI for supporting alternative and more complex flows for adding accounts.
All parameters are now collated into a single "validated input" object which is more convenient to pass around between views
This makes it possible to support back- and forth navigation between "basic" and "advanced/details" forms for adding accounts.
Additionally it provides a fundamental building block for adding alternative ways to add accounts (e.g. via OTP token URI/QR code).
Issues: #7
With this the AccountStorage module now fully supports some HOTP/TOTP parameters which are uncommon (but still part of HOTP/TOTP specifications).
- Better types for offset, tokenLength. Make this consistent throughout
- Finish support for offset, checksum parameters for HOTP tokens in AccountStorage
- Finish support for hashing algorithm, epoch parameters for TOTP tokens in AccountStorage
- Better API for creating oath::Algorithm instances
- Code formatting (break up long lines)
Issues: #7
With this change account storage and model work with accounts for which an issuer is recorded.
This is a prerequisite for fully supporting otpauth:// URIs (necessary for QR code support) in Keysmith.
Issues: #7, #13
See-Also: https://github.com/google/google-authenticator/wiki/Key-Uri-Format
situation is not super nice, but in general several problems exist,
- some files do not include any license, assumption is unless specified
explicitly they follow same license as the source package
(GPL-3.0-or-later).
- most files do not include the proper copyright statement, I have
specified KDE Localization team as copyright contact.
- license files do not follow SPDX headers, so we need to add them in
dep5.
I will start a thread in kde-core-devel / kde-i18n-doc mailing list
about licensing situation once 0.2 release is out.
Johan Ouwerkerk
l10n daemon script
Bhushan Shah