An app::Navigation class is introduced with an API very similar to the
Kirigami.PageRouter in QML. This new class is responsible for pusing
populated view model classes from C++ into QML ownership and triggering
appropriate navigation events. On the QML side a signal handler
forwards these calls to the Kirigami.PageRouter to perform the actual
navigation in the UI.
This construct paves the way for moving state transition and related
logic out of QML and towards C++, since this logic is currently mostly
concerned with page navigation in Keysmith. Ultimately that transition
should make the QML (page) views more easily re-usable.
Replace existing manual manipulation of the application page stack with
a more declarative setup using Kirigami.PageRouter. This change does
not yet address the control flow: pages are not yet properly decoupled.
With this change the user now gets appropriate error feedback when trying to unlock their accounts using an incorrect password.
Additionally password entry is temporarily suspended in the UI while key derivation (etc.) is in progress.
This should help convey the idea that "something is happening", or rather avoid the impression that "nothing happens" or "this is broken" when in fact key derivation may simply be slow depending on the machine.
The feature to accept accounts from the command line via otpauth:// URI inadvertently broke the initial password setup flow.
With this change password setup and unlocking should now work correctly again in all cases/flows.
Issues: #14
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
With this change Keysmith now prompts the user to either:
- setup a new password
- supply an existing password (if detected)
Additionally the organisation/structure of the QML is cleaned up a bit.
All QML pages are dedicated QML files and a few signals are introduced
to provide slightly better encapsulation/decouple interdependencies.
This change fixes input validation for the following cases:
- Check that entered account names are still available
- Working validation for time steps (input mask was completely broken)
- Allow longer tokens: liboath is no longer used, Keysmith can handle it
Additionally the QML code is refactored significantly:
- Extracted the main accounts overview page
- Extracted the add an account page
- Completed the internal renaming of "Oath" to "Keysmith" for QML types
The account details page has a kind of modality:
- hide mode: in which the user is shown the account info but sensitive information such as secret keys should not be displayed openly visible.
- show mode: the same, but in this case all details are openly visible. This will be useful for showing QR codes explicitly.
- edit mode: in which the user may edit account details (all except the name).
Due to our use of liboath for generating the actual tokens, we also support only a limited range of valid token lengths.
This means that it is more user friendly to express those limits directly in the UI through a SpinBox instead of allowing the user type in values we do not currently support.
It uses the oath-toolkit[1] provided library liboath to generate the 2FA
codes, both TOTP and HOTP based. Currently it is largely untested. From
initial rough testing it seems that auto-refreshing of code is not
working. Also button to refresh token for HOTP is also dummy at moment.
Some todo items include,
- Verify the generated oath code is correct
- Make refreshing token work
- QR code scanning
- Backup and Restore of accounts
- Clipboard support to automatically copy code.
- Encrypted storage of the secret token
This code is largely based on the authenticator-ng[2] application by the
Rodney Dawes and Michael Zanetti for the Ubuntu Touch.
[1] https://www.nongnu.org/oath-toolkit/
[2] https://github.com/dobey/authenticator-ng
Nate Graham
Johan Ouwerkerk
Bhushan Shah