Introduce flowpilot #962
Draft
Introduce flowpilot #962
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Co-authored-by: Frederic Jahn <frederic.jahn@hanko.io>
Co-authored-by: Frederic Jahn <frederic.jahn@hanko.io>
…anges add optional config attributes
* feat: flowpilot flows can start with a subflow * chore: improve flow validation and validation error messages Co-authored-by: Frederic Jahn <frederic.jahn@hanko.io>
* flowpilot login flow WIP * adjust login flow * flowpilot generic client updated and moved, examples deleted * adjust login flow, fix passcode template rendering * login flow adjustments * adjust login flow to use the new username field * fix registration identifier test * chore: improve check for email address * fix mail templates * feat: flowpilot subflow for passcodes (#1187) * chore: error messages improved * chore: adds subflow for passcodes --------- Co-authored-by: bjoern-m <56024829+bjoern-m@users.noreply.github.com> Co-authored-by: bjoern-m <bjoern.mueller@hanko.io>
The persister now loads the password credential from the DB. It also loads the webauthn credential transports from the DB now.
When generating the response after an action execution, schema generation and initialization of actions for the next state are skipped if the execution result already contains an execution schema (which should be the case if the action executed successfully). This leads to problems when the action that was executed is also an action for the next state (which is the case for profile actions, where e.g. after deleting an email the flow returns to the profile init state, which again may offer to execute the same action again, i.e. delete additional emails): if the action execution leads to a state (of data) where the "next execution" for the same action then should be suspended and the action should not be part of the response (e.g. when trying to delete the last webauthn credential if webauthn is the only auth method configured), then skipping the initialization results in creating a response based on old/stale data, i.e. the action is part of the response and is "offered" as a valid action when it actually should not. This commit fixes that by removing the check for an existing exexution. This has the drawback that the action is initialized twice.
This should no longer required due to the dedicated profile dto struct.
Rename the hook to make it more obvious that it is resonsible for persisting the verification status for an email after verification. Move it to the shared package because the login flow also needs it, e.g. if email verification was activated retroactively and users logging in with previously unverified email addresses also correctly have said email's verification status set to verified. Add a noop case if the email address already exists and is also already verfified.
Skipping schema generation for the next state actions if the schema already existed was previously removed. This results in errors added to inputs during execution not being part of the response because a new schema without error information was generated. This change reverts this. If any action changes data such that it leads to a state of data where the same action should be suspended for the next execution (esp. in case of the profile where successful actions result in the same state as the previous one and where the same action might be part of the available actions) then the action can/should now check the new state of data for suspension during execution and then set a flag on the context/execution result accordingly (capabilites to do so are introduced with these changes). Schema generation is then skipped if there already is a schema and if the suspension flag is set to true.
Allow hooks to be run before each action. Introduce Finalize interface method for actions.
* fix: nil pointer exception when accessing the flow error
* feat: passcode handling when email is unknown * feat: new passcode templates and improved behaviour to prevent email address enumeration
Co-authored-by: Frederic Jahn <frederic.jahn@hanko.io>
- Modifies the send_capabilities action by adding a new input for providing information about availability of conditional mediation on a client and stashing the value for further use. - Adds and applies a login flow hook that generates WebAuthn request options before the login_init state if conditional mediation is available (see point above) and applies the options to the response payload. - Applies the existing action for verifying a WebAuthn assertion to the login_init state. Because said action is now used on both mediated and un-mediated logins, it needs to know both the state the flow is in and the information about mediation availability in order to correctly suspend the action in the login_init state. Therefore I extended the InitalizationContext interface with a method to check whether the current state of a flow equals some other state. For this to work, the default implementation of the InitalizationContext had to be extended with a field to hold the FlowModel in order to have access to state information.
* feat: introduce flow-api sdk and adjust the response --------- Co-authored-by: merlindru <hello@merlindru.com>
* chore: add back-action to the password creation state * fix: webauthn service errors corrected * chore: add back-action to the login passkey state * fix: the 'public_key' input of the verify attestation action is a string type * chore: add back-action to the profile verify attestation state * chore: set default PublicActions to the PublicResponse struct, when creating a flow result * fix: after state hook to persist webauthn creds returns an error * chore: also introduce the back-action to the passkey onboarding subflow
* fix: nil pointer exception while validating min and max length * chore: change public_key input type to json * chore: add the actual username to the related input field * chore: add a value for max_length to the password input
* feat: add user data to payload on success * Update backend/flow_api/flow/shared/hook_get_user_data.go Co-authored-by: Lennart Fleischmann <67686424+lfleischmann@users.noreply.github.com> --------- Co-authored-by: Lennart Fleischmann <67686424+lfleischmann@users.noreply.github.com>
* feat: hanko elements with flow api
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Implementation
Tests
Todos
Additional context