Closed fremartini closed 3 months ago
Attention: 7 lines
in your changes are missing coverage. Please review.
Comparison is base (
bc0fa26
) 72.36% compared to head (fce0515
) 73.77%. Report is 2 commits behind head on main.
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
I have a few thoughts:
AuthenticationCubit
vs server-sideI see a few issues with tracking session timeouts locally within AuthenticationCubit
:
Right now, the session timeout depends on the device's time (dateService.currentDateTime
). This could get tricky if someone's device time is off. I'm thinking a server-side solution might be more foolproof, as it keeps the time check consistent and out of the user's hands (and our code).
The code checks for session expiration only when the app starts up (appStarted
method). What if the app stays open past the session timeout? It might be better if the app could actively monitor the session status and log out automatically when time’s up, even if it's still running.
Adding session timeout management into AuthenticationCubit
increases code complexity by quite a bit. Handling this on the server-side might simplify our code and let AuthenticationCubit
focus just whether the user is logged in or not.
I think tackling session timeouts on the server could really streamline things. It might also make features like "auto-logout after X inactive hours" easier to manage since the server would just reset the session timer with each valid request.
Also, about the changes to Dropdown
and SettingListItem
- they seem to be doing things a bit differently now. We should probably stick to keeping these components simple to avoid any unexpected behaviors. For instance, we don't want any complex behaviour in a setting list item - see how we open a new page for other settings that requires text input or a selection from a list. How the app handles session timeouts UX-wise also needs to be discussed before we try for a new implementation. For instance, does the user even need to be able to choose the expiration time themselves?
I appreciate the effort you've put into this PR, but for now, I'm closing this PR. To get this feature up and running we should discuss the implementation details further in https://github.com/AnalogIO/analog-core/issues/238 before attempting to implement this client-side.
closes #169