Hooks that can control "flows" (a.k.a blocking hooks)

[harnash]

Hi!

In this #1289 where webhooks were implemented there was and idea hinted about implementing hooks in a way that they can interrupt/influence flow they are part of. For example in login flow hook may be used to trigger some additional checks or execute some complex business logic and depending on the results it may abort the flow (returning an proper error/message) or follow with the standard flow if status returned by hook allows.

I still have to take a look at the code but I was wondering what are your thoughts about this and if the are any special consideration that we should make while working on this?

[aeneasr]

Yeah I think this would be great. One consideration would be that the hook could update the flow, so that we can share information about the reason why the flow failed with the UI

[harnash]

That is exactly what we want to achieve. We would like to avoid adding some complex logic into Kratos and delegate that outside to some service and keep it relatively simple from Kratos perspective.

[harnash]

One question so far: I'm propagating errors via web hook functions and if I understand correctly right now flows can only return one error to the UI - I mean that only one validation error is returned thus only one field can be reported as violating constraints in the API response? Is that correct?
I see that there is flow.UI.Messagess.Add() but I'm not 100% sure how should I deal with it.

[harnash]

OK. Looks like I have it somewhat working. Issue that popped up is that flow.UI is not properly updated when hook error is reported causing form to be reset (it is only updated in strategy.* calls via handleRegistrationError().

[aeneasr]

I mean that only one validation error is returned thus only one field can be reported as violating constraints in the API response? Is that correct?

No, it should be possible to add multiple validation errors to the UI!

Issue that popped up is that flow.UI is not properly updated when hook error is reported causing form to be reset (it is only updated in strategy.* calls via handleRegistrationError().

Ah yeah, totally possible that there are some issues where this isn't properly being updated as we did not have anything for dealing with hooks & ui messages yet.

[harnash]

OK. I need to add some tests and I'll present the initial PR. There are some things to discuss there. Hopefully I'll manage to wrap it up till weekend. Having form reset is not ideal but for the initial approach and testing it is good enough. Funny thing is that if for some reason strategy fails it saves the form data ;-) ... and yes I got the multiple errors properly propagated to the UI finally.