In the #68 investigation, the reporter's --auth-per-child run (narrow x-childfilter to one child and re-run AuthenticateAulaUser, the shape two other Aula clients use) produced byte for byte the same result as the SwitchChild flow. It may be the better mechanism because nothing depends on server-side session state, which would also remove the need for the lock and the confirm step.
The #68 fix shipped SwitchChild because that was the validated path at sign-off time. This issue tracks deciding whether to move.
To resolve:
- Test auth-per-child across more than one institution type, especially the ones where
AuthenticateAulaUser omits child.
- Check whether re-authenticating per child adds noticeable latency for guardians with many children.
- If adopted, the lock in
_read_easyiq_week and confirm_easyiq_session_child can likely go.
In the #68 investigation, the reporter's
--auth-per-childrun (narrowx-childfilterto one child and re-runAuthenticateAulaUser, the shape two other Aula clients use) produced byte for byte the same result as theSwitchChildflow. It may be the better mechanism because nothing depends on server-side session state, which would also remove the need for the lock and the confirm step.The #68 fix shipped
SwitchChildbecause that was the validated path at sign-off time. This issue tracks deciding whether to move.To resolve:
AuthenticateAulaUseromitschild._read_easyiq_weekandconfirm_easyiq_session_childcan likely go.