Minimal support for requesting window activation in response to
activation requests from D-Bus.
This provides minimal support for xdg D-Bus activation in Keysmith:
only the activation signal itself is handled; the DBus API for opening
URLs is not implemented.
Issues: #18
This change provides the most basic D-Bus support in Keysmith.
At start up, Keysmith will now register itself and abort if another
instance is already running. Full support for the xdg D-Bus activation
specification (such as URI opening) is not yet implemented.
By default this feature is disabled on Android, but enabled on 'all'
other platforms. Explicit control may be exercised by running CMake
with -DBUILD_DBUS_INTERFACE=<ON|OFF>.
Issues: #18
Turns out it is not needed to check whether an action is enabled before
triggerin it: the trigger is automatically suppressed if the action is
not yet enabled.
Add a 'proxy' to forward external API calls into the main application
control flow. Right now it only supports forwarding commandline
arguments, but this construct is already useful as a starting point for
future D-Bus API support.
This change prepares Keysmith for moving logic away from QML to C++
- Added view model classes for each defined Navigation::Page instance
- Added 'flows' to provide a C++ equivalent for control flow logic
which currently still resides in QML
The purpose the view model classes is to provide data (properties) and
actions (methods to invoke) to the QML page UI. These are relatively
thin wrappers to expose the C++ state (Store) and logic (flows) as an
easy to use API for the QML UI.
The 'Store' is a convenient wrapper for injecting a dependency on the
entire application state (root) so it can be re-used by independent
flows of C++ logic. It will be used both to provide data to the view
models for the QML UI, and as a way to record results of actions
dispatched from the UI.
With this change the following (additional) state is defined:
- OverviewState, which will be used to track state that determines how
the AccountsOverview QML UI should render and what features are
enabled/disabled in it. This state may be manipulated as a a
side-effect of various interactios with arbitrary pages.
- FlowState, which will be used to track state about which control/
logic flows have completed and whether or not something is currently
running. This is will be used to avoid distracting the user from an
active UX flow with random unrelated prompts.
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.
Needed to support automatic migration of old Keysmith storage format.
This is unfortunate, but we have users and we cannot simply break
backwards compatibility with the old storage format (yet).
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.
Previously entering an incorrect password would appear to successfully "unlock" accounts, contrary to expectations.
By introducing a challenge object as part of the master key parameters, an incorrect password can now be detected and signalled accordingly.
This fix introduces a backwards incompatible change to the accounts data as stored on disk, meaning old Keysmith accounts configuration will no longer load and must be recreated from scratch.
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
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
Nate Graham
Devin Lin
Tobias Fella
Johan Ouwerkerk
Bhushan Shah
Carl Schwan