Implement continuations in the portal login flow
Summary
The LemonLDAP::NG portal is centered around the idea of running a list of methods (with do
) in order.
(extractFormInfo, getUser, etc)
But this flow generally needs to be interrupted at some point for user interaction:
- Entering credentials
- Entering 2FA
- Showing notifications
- Showing info
- etc.
Each component of LemonLDAP::NG has its own way of doing that. Generally a OneTimeToken is used, but not always.
- Issuer saves the request environment
- 2FA saves sessionInfo + a couple other fields
- Notifications encrypt the session cookie but require $req->data->{url} to be persisted
- etc.
There are literally dozens of bugs, maybe more, caused by the fact that the
current $req
object needs to be serialized before the interaction and
restored after, and this is done incorrectly.
There are many bugs caused by interactions that arise for the fact that some
early part of the processing sets something in $req->data
that is needed
later, but not restored correctly.
There are also many bugs caused by the fact that some extra steps are stored in
$req->steps
but not restored after an interaction.
Design proposition
We need to create a generic system for storing the request state during a user
interaction, including $req->steps
. This system should be used by every part
of LemonLDAP::NG that needs to interrupt the current flow to display a page.
I will update this issue with a design proposal later, but it will take a lot of time to implement this correctly, and require many preliminary steps.